Forum / Remote Desktop Manager - Support

Problem with Key Agent & Key Forwarding since latest updates

  • Create an Issue
  • Cancel

I recently updated to 2019.1.3.0, then to 2019.1.5.0, and finally to 2019.1.6.0 (64-bit) on Windows 10. There seems to be a problem with the Key Agent since about version 2019.1.3.0.


When I start the Key Agent Manager I am prompted to enter the private key's password, I can then see the key's details (version: SSH2, key size 4096, etc). When I try to start an SSH terminal session I get the following message:

"An unknown SSH error was encountered"

"Disconnecting"

All my SSH connections are set up in pretty much the same way with an override terminal type set to "linux", and on the advanced tab both the "Use SSH authentication agent" and "Allow SSH authentication agent forwarding" ticket

I have enabled logging and this is the log output:


[16/05/2019 15:07:05] Setting up connection
[16/05/2019 15:07:05] Connecting as *********
[16/05/2019 15:07:05] SSH banner: SSH-2.0-OpenSSH_7.2
[16/05/2019 15:07:05] Sending kex init
[16/05/2019 15:07:05] Received kex init
[16/05/2019 15:07:05] Selected algorithms: curve25519-sha256@libssh.org, ssh-ed25519, chacha20-poly1305@openssh.com, chacha20-poly1305@openssh.com, implicit by cipher, implicit by cipher, none, none
[16/05/2019 15:07:05] Sending Ed25519 kex init
[16/05/2019 15:07:05] Received Ed25519 kex reply
[16/05/2019 15:07:05] Successfully authentified server
[16/05/2019 15:07:05] Sending new keys message
[16/05/2019 15:07:05] Sending userauth service request
[16/05/2019 15:07:05] Received new keys message
[16/05/2019 15:07:05] Received service accepted message
[16/05/2019 15:07:05] Agent has no keys
[16/05/2019 15:07:05] Disconnecting

The thing is, the key is certainly valid. I tested it by loading Git Bash, then starting the agent and adding my key:

eval `ssh-agent -s`
ssh-add -k


I then type my password and ssh to the same server. Once connected, I can verify the agent forwarded the key by typing:
ssh -vT git@bitbucket.org

After a few seconds I can see my connection to BitBucket was successful:


"logged in as *********"


If someone could take a look at this issue it would be greatly appreciated

Thanks,

Clock10 mths

Hello,

Thank you for the report, we'll take a look at the issue. If we have any further questions to help us find out what's wrong, we'll ask you.

As a workaround, you could use the legacy terminal. You can set this by going in File > Options > Types > Terminal, and checking "Use legacy terminal".

Regards,

Hubert Mireault

signaturesignature

Clock10 mths

I can confirm the legacy terminal is working correctly. After changing the setting to use the legacy terminal, I restarted RDM, enabled the Key Agent Manager, and connected to a server. My SSH key is forwarded correctly to that server and I can connect to BitBucket


Thanks

Clock10 mths

Hi,

I have tried to reproduce your bug but without success. There is something I would like you to try: could you stop the Key Agent Manager, and try connecting with one of your sessions, without changing it, using the legacy terminal. I wish to know if the connection is really established using the agent: the legacy terminal is trying all the credentials it can get until they all failed. And to be sure, you're using an RSA key, is that correct?

Thanks

Denis Vincent

signaturesignature

Clock10 mths

I can confirm, this is still the case with

2019.1.25.0 64-bit
Today I tried nearly all possible combinations to use a password protected private key with the agent - no way!

For the purpose of reproducing could you please describe what exactly I should do to make you believe something is wrong here?

The following is my test szenario.

1. local RDM data source type SQLite
2. Add Credential Entry -> Private Key
Private Key Type: Data
-> paste the key ( I tried password protected putty format and password protected ssh-keygen format )
-> Enter the passphrase for the private key
-> Uncheck [ ] Always prompt for passphrase
Advanced -> [x] Automatically load to key agent
3. OK to Save

Now I start the SSH Key Agent and it will show the key as

SSH2 4096 SSH_RSA <no comment> <fingerprint>

Btw. I tried different SSH-key algorithm including ones generated with the RDM SSH keygenerator.

Then I created a new Session with

GENERAL
Host: <ip of host>
Username: username to use
Password: <empty>
PRIVATE KEY
<no private key>
ADVANCED
[x] Use SSH authentication agent

Result:

An unknown SSH error was encountered.
Disconnecting

I have the following additional questions to this procedure. How does RDM determine which key to use by this method which is described in the docs?
Let's assume I have 100 SSH-Keys stored in the SSH-Agent. Which one will be used??

When I remove the checkbox [ ] Use SSH authentication agent from the credential entry and configure the SSH-Key for the remote session manually as

PRIVATE KEY
Private Key type: Repository
Vault: SSH logins\id_rsa_rdp
Passphrase: <greyed out>

the connection works !!!


Thanks for that great tool but you should definitely invest some time in fixing this. Using SSH-Keys via Agent, where the agent unlocks the keys is an essential feature!

Regards

Peter

Clock9 mths

@krasnojarsk Hi Peter

I believe there is something wrong, I just can not reproduce it. I also do not have enough info to debug this problem, and did not get any answers to my last questions.

So the first thing you could do to help me correct this would be to post the logs for the failed connection. In the "Advanced" tab, check "Verbose", check "Enable logging", specify a file path in the "Log path" text field, set the "Log mode" to "Event". One other thing that could help me solve this issue is if you could try using the Putty key agent (Pageant) and see if you get the same result. You can either use RDM's Key Agent Manager or the standard Putty key agent, but only one at a time (they both refuse to start if the other is active).

To answer your question, if the agent has more than one key, they are tried one after the other. In order to save time and processing power, the server is first asked if it knows a key. Once it is established that a key is know by the server, a full authentication request with signature is sent to complete the client authentication.

Sorry if it looked like we were ignoring this issue. But in order to solve this, I will need feedback.

Regards

Denis Vincent

signaturesignature

Clock9 mths

I will try to log the problem next week in a traceable way, e.g. screenshots, logs etc. if my normal work allows it.

Clock9 mths

Hello Denis,

I had time to do some tests. I added 2 PDFs (containing Screenshots and the logs) to this post. As far as I can tell, the agent always thinks it has no key for that connection.

I first tried a connection via SSH with an SSH-Key Credential and that worked. After that I used the agent with the same key, the agent with the same key from a file in openssh format and the agent with the same key from file in putty format. - Nothing worked!

To your answer, that you can not reproduce it I have to say it is not hard to create an SSH key pair and test it on a server.

Regards

Peter

working.pdf
Failing.pdf
Clock9 mths

Hi Peter,

I am still trying to figure out what is going wrong. Could you do a test for me: use the legacy terminal with verbose and send me the resulting logs when connecting using the key agent.

Regards

Denis Vincent

signaturesignature

Clock9 mths

What do you mean exactly by "Legacy Terminal"?

Clock8 mths

Hi Peter,

The legacy terminal is the previous implementation for the SSH terminal. You can set it in File -> Option -> Types -> Terminal and check "Use legacy terminal".

But this should change nothing to the problem with the Key Agent Manager, because we recently put the finger on the bug. On the other hand, while we make the required changes, there is a work around. Once all your setup is done, close RDM and restart it, then start the Key Agent Manager just once. It should work as expected. If you interact with the Key Agent Manager after that, all new modifications will not be seen by other agent clients like the terminal.

I will be working on this issue as soon as possible. It will require some amount of work though so I can not give you any time frame for now. It could range from a week to a month I guess.

Regards

Denis Vincent

signaturesignature

Clock8 mths

Hi Vincent,

while you have "your finger on the bug", I think there seems to be also a bug in creating ssh tunnels. I have all of them working in MobaXTerm and Putty but no chance to get it working with Remote Desktop Manager. The only way I could get this tunnel (see image attached) working was to create it in Putty and then import the putty session, which is not an option because of the ugly putty interface and no way to change anything afterwards. So maybe while looking at the code for the key agent you stumble upon some other "related" things?

See attached images for info what I want to accomplish and works with MobaXterm and putty but not with RDP Manager

Regards

Peter

2019-06-27_16h05_07.png
2019-06-27_16h05_42.png
Clock8 mths

As far as I can tell now (testing with RDM 2019.1.41.0) SSH tunnel seem to work now. I tested a "Remote port forwarding" tunnel, where the remote host (192.168.1.17) forwards its port 8088 to my localhost (127.0.0.1:8080). This is the way I use a local proxy running on the host where I use RDM to allow the remote host to update via https through my local running proxy. I could also authenticate the tunnel using SSH-Keys but only ones I store for the session.
I could again and still not use the same key from the SSH-Key-Agent.

When trying to use the SSH-Key-Agent as source for the key it always prompts for the password while there is none when using the SSH-Key (the key has no password). After entering the correct password when using the SSH-Key-Agent the tunnel works but I assume it is established using the password not the key.

I can see some progress but there still are some bugs. Don't you have a host to test things out? I am willing to spin up a 5$ Droplet on Digital ocean just to give you the opportunity to test these things out.

Regards

Peter

Clock7 mths

Hello,

I'm glad that the SSH Tunnel works fine now, regarding the SSH Key Agent. A ticket has been open for Denis, He's currently on vacation, and I prefer to wait for his return for better fixe.

While we are looking at the issue if you found anything else, please let us know.

We also appreciate the offer for a test infrastructure. Denis will look at this and inform you if he needs it.

For further follow up the ticket number is RDMW-3391

Best regards,



David Grandolfo

signaturesignature

Clock7 mths

Hello,

In the latest version of RDM 2019.2.22.0, we integrate a new SSH Key agent.

Could you test it and inform us it works well for you.

If you are using the current key agent, just download the new RDM and test it as is, nothing special need to be performed.

Best regards,



David Grandolfo

signaturesignature

Clock3 mths

Hi,

I can confirm an imported key works with the agent. I tried the regular and also the legacy terminal under the following circumstances:

just ignore the lines with POSSIBLE BREAK-IN ATTEMPT


MobaXTerm with ED25519 key (just to verify)
Dec 12 07:50:34 linux.host sshd[1956]: Address 192.168.2.44 maps to mycomputer.mydomain, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 12 07:50:34 linux.host sshd[1958]: Address 192.168.2.44 maps to mycomputer.mydomain, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 12 07:50:34 linux.host sshd[1958]: Received disconnect from 192.168.2.44 port 57392:11: No more authentication methods available [preauth]
Dec 12 07:50:34 linux.host sshd[1958]: Disconnected from 192.168.2.44 port 57392 [preauth]
Dec 12 07:50:34 linux.host sshd[1956]: Accepted publickey for root from 192.168.2.44 port 57391 ssh2: ED25519 SHA256:WoHaHereYouWouldSeeSomeKeyStuffbutIremovedIt


Remote Desktop Manager with ED25519 defined at connection level
Dec 12 07:52:40 linux.host sshd[1989]: Address 192.168.2.44 maps to mycomputer.mydomain, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 12 07:52:40 linux.host sshd[1989]: Connection closed by 192.168.2.44 port 57400 [preauth]
Dec 12 07:56:28 linux.host sshd[1994]: Address 192.168.2.44 maps to mycomputer.mydomain, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 12 07:56:28 linux.host sshd[1994]: Accepted publickey for root from 192.168.2.44 port 57407 ssh2: ED25519 SHA256:WoHaHereYouWouldSeeSomeKeyStuffbutIremovedIt


Remote Destkop Manager with ED25519 imported to SSH-Agent
Dec 12 08:09:36 linux.host sshd[2035]: Address 192.168.2.44 maps to mycomputer.mydomain, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 12 08:09:36 linux.host sshd[2035]: Accepted publickey for root from 192.168.2.44 port 57437 ssh2: ED25519 SHA256:WoHaHereYouWouldSeeSomeKeyStuffbutIremovedIt
Dec 12 08:13:11 linux.host sshd[2057]: Address 192.168.2.44 maps to mycomputer.mydomain, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
Dec 12 08:13:11 linux.host sshd[2057]: Accepted publickey for root from 192.168.2.44 port 57440 ssh2: ED25519 SHA256:WoHaHereYouWouldSeeSomeKeyStuffbutIremovedIt


So far it seems to work since all 3 tests show the same result. One quick question afterwards. I don't know for sure but I somehow remember that there was the possibility to import a key into the SSH-Agent via Clipboard and not only by file. Is that gone or am I wrong?
I ask because I want to know what happens if I import a key from file into the SSH agent. Is the key then stored within Remote Desktop Manager or does the agent still point to the file? As you can imagine if it only points to the file, the file could be deleted. Maybe you could point out that a little bit for better understanding. I assume when adding a private key within a connection entry it is definitely stored within the Database Backend (in our case Enterprise with MSSQL).

Thanks for following up

Kind regards

Peter

Clock3 mths

Hello,

Thanks for the detailed tests, Peter. If any issue occurs with the new agent, please let us know.

To answer your questions:
1. The possibility to import a key into the SSH Agent with the clipboard isn't supported.
2. If you load a key from a file, RDM will only store the path to the file to reload it automatically, so you would be right thinking that if it is deleted, RDM wouldn't be able to load it anymore. In this case, we recommend storing them as data in a private key entry in your vault. You can set these entries to load in the agent automatically.

Regards,

Hubert Mireault

signaturesignature

Clock3 mths