Start a new topic
Answered

WarpGate Support - SSH Password and Key Authentication

I am setting up a warpgate SSH Proxy and for authentication I need to pass my username and for a password I need to put the host that I want to connect to.

The password is how WarpGate determines which internal host to route to since SSH does not have SNI like an HTTP reverse proxy would use.

I also need to send my private key to authenticate my username to WarpGate as the password is simply the host I want to connect to.

Currently, as far as I can tell, RTS support either password or key, but not both.


I am also open to recommendations for a better way to reverse proxy SSH.


Best Answer

I find it interesting that you are parsing it in such a way.

It is commonly used as a connection string to be USER:PASSWORD@HOST:PORT.

I would think that your parsing logic should split at the @ symbol, then split the 1st section on the : to get the username and password and the 2nd section at the : to get the host and port.

That being said, I'm not sure how this translates to the application as there are separate fields for user and password as well as host and port in the connection properties.


Your comment actually got me thinking and I tired one more thing.

In the credential for the connection, I put the RoyalTS:styx.dmz.example.com as the username without filling in the password field and selected my private key as well with the Rebex plugin.

This actually worked, so I'm not sure anything code based needs to change, unless you want to add a checkbox to enable the sending of both the password and private key, then I don't have to have a funk username and it would be more obvious to future users.


Hi Austin,


that is correct. If a key is specified the password is not used. There might be the need for a passphrase in case your key file is protected using one.


Regards,
Stefan

Thanks for the reply Stefan.


My key does not have a passphrase, for this application I am required to use both password and key auth.


I also looked into using SSH JumpProxy as an alternative, but I haven't been able to get that to work with the Rebex plugin.

Is PuTTY working that way? If so, how do you configure PuTTY exactly?

I hadn't tried with Putty yet, but here is in Powershell 7.

PowerShell 7.3.6
PS C:\Users\Austin> ssh -i <PATH_TO_KEY_FILE> RoyalTS:styx.dmz.example.com@192.168.127.2 -p 2222
 Warpgate  Selected target: styx.dmz.example.com
 Warpgate  Host key (ssh-ed25519): AAAAC3NzaC1lZDI1NTE5AAAAIEe53izW3TzMqppiS1R5cOlm0sqRvVBGaXdxM3/NkgYv

 ✓ Warpgate connected
Last login: Wed Aug 16 13:11:37 2023 from 192.168.22.202
[admin@styx ~]$

So now, I tested with Putty, standalone, not in RTS.

In the host name and port I used RoyalTS:styx.dmz.example.com@192.168.127.2 port 2222.

I then included the private key in the SSH Auth settings.

Using username "RoyalTS:styx.dmz.example.com".
Authenticating with public key "REDACTED"
 Warpgate  Selected target: styx.dmz.example.com
 Warpgate  Host key (ssh-ed25519): AAAAC3NzaC1lZDI1NTE5AAAAIEe53izW3TzMqppiS1R5cOlm0sqRvVBGaXdxM3/NkgYv

 ✓ Warpgate connected
Last login: Wed Aug 23 21:39:45 2023 from 192.168.127.2
[admin@styx ~]$

 

Hi Austin,


I guess it should then also work in Royal TS (using the PuTTY plugin) - assuming the whole thing also works with settings/cli arguments. Can you try to setup the connection in Royal TS?


Regards,
Stefan

Hi Stefan,


I did not see an area to configure the Putty plugin in this way.

I was looking for an area to append additional CLI options in the connection properties.

I did see a bunch of options under Advanced, but nothing like this.

Hi Austin,


maybe we can approach this the other way around. Can you tell me which command line options you are using to make it work to automatically log you in the way you want? Then I can see if we can setup a PuTTY connection using these options or if we need to extend Royal TS to enable it.


Thanks,
Stefan

I was able to successfully connect using this command line.

  

putty -ssh RoyalTS:styx.dmz.example.com@warpgate.example.com -P 2222 -i <PATH TO PRIVATE PPK>

  

I think the problem is the : in the host name. When we find a : we assume that hostname and port is specified and we parse both parts. In this case it doesn't work because everything after the : is not a valid port, so we are using the default port and everything before the : we use as URI.


I improved the logic a bit and implemented an additional validation to see if the stuff after the : is really a valid port. If it is not, like in your case, I return the whole string as URI. So the next release should behave differently and hopefully correctly.


If you can somehow configure your warpgate to not use : as a separator, you may be able to work with the PuTTY based plugin in Royal TS right now, otherwise I can provide an internal build for you to test. Let me know if you want to test that build.


Answer

I find it interesting that you are parsing it in such a way.

It is commonly used as a connection string to be USER:PASSWORD@HOST:PORT.

I would think that your parsing logic should split at the @ symbol, then split the 1st section on the : to get the username and password and the 2nd section at the : to get the host and port.

That being said, I'm not sure how this translates to the application as there are separate fields for user and password as well as host and port in the connection properties.


Your comment actually got me thinking and I tired one more thing.

In the credential for the connection, I put the RoyalTS:styx.dmz.example.com as the username without filling in the password field and selected my private key as well with the Rebex plugin.

This actually worked, so I'm not sure anything code based needs to change, unless you want to add a checkbox to enable the sending of both the password and private key, then I don't have to have a funk username and it would be more obvious to future users.

Hi Austin,


glad it's working this way for you.


As for the parsing logic:

The way we parse the URI was changed at a later point. Originally we did not any parsing because we have URI, Port and credentials as separate configuration fields. The reason we are only supporting hostname:port parsing for the URI is because it enables users to leverage replacement tokens to be used for the port. The port field is an integer and doesn't allow to put in any text string. So when we find a port configuration in the hostname, we prefer that to the configured port. Since we don't support that for user/password in the URI, we only parsed for the port.


In any case, the changed code base should not interfere with your workaround and should also enable you to use the computer name field as well.


Regards,
Stefan

Awesome, thank you.

You're welcome!

Login or Signup to post a comment