WarpGate Support - SSH Password and Key Authentication
A
Austin Arbour
started a topic
over 1 year ago
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
A
Austin Arbour
said
over 1 year ago
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.
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
A
Austin Arbour
said
over 1 year ago
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.
Stefan Koell
said
over 1 year ago
Is PuTTY working that way? If so, how do you configure PuTTY exactly?
A
Austin Arbour
said
over 1 year ago
I hadn't tried with Putty yet, but here is in Powershell 7.
So now, I tested with Putty, standalone, not in RTS.
In the host name and port I used RoyalTS:[email protected] 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 ~]$
Stefan Koell
said
over 1 year ago
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
A
Austin Arbour
said
over 1 year ago
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.
Stefan Koell
said
over 1 year ago
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
A
Austin Arbour
said
over 1 year ago
I was able to successfully connect using this command line.
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.
A
Austin Arbour
said
over 1 year ago
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.
Stefan Koell
said
over 1 year ago
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.
Austin Arbour
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.
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.
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstStefan Koell
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
Austin Arbour
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.
Stefan Koell
Is PuTTY working that way? If so, how do you configure PuTTY exactly?
Austin Arbour
I hadn't tried with Putty yet, but here is in Powershell 7.
So now, I tested with Putty, standalone, not in RTS.
In the host name and port I used RoyalTS:[email protected] port 2222.
I then included the private key in the SSH Auth settings.
Stefan Koell
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
Austin Arbour
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.
Stefan Koell
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
Austin Arbour
I was able to successfully connect using this command line.
Stefan Koell
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.
Austin Arbour
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.
Stefan Koell
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
Austin Arbour
Stefan Koell
You're welcome!
-
What happened to the forum?
-
About this Forum
-
Security Information
-
Supported Secure Gateway (SSH) ciphers
-
Why is no remote file browser in SCP available?
-
What encryption is used in the rtsz files when enabled?
-
Royal TS V4 License File
-
How to resolve RDP resolution issues in Windows 7 with high resolution screen
-
Auto Fill in web page connection
-
How to reference custom properties in tasks and templates?
See all 276 topics