jrhett

Do you mean verbose log from ssh client, aka "ssh -vv server" or do you mean an RDM log of the interaction where I'm forced to kill off RDM?

Any updates on this? Right now I'm having conversations every hour with people who are newly being forced to RDP via newly implemented bastions, and they are asking what they can pay for to simplify the two-step process and I don't have an answer for them.

I'm very glad to hear this. Looking forward to it!

Those logs are from the third party library we're using for the SSH protocol. My guess is that they use the same log text for both key request and key signature. When authenticating with keys, it is usually performed in 2 steps: first a request is made sending the public key in order to know if the server knows that key, then, if the first request succeed, a second request is sent that provides a signature for the real authentication. It is done this way to avoid expensive computing of a signature that the server wouldn't even check because the key is not allowed in its authorized_keys file.

I was writing "oh that makes sense" when I realized it doesn't. My tests had keys that were not in the authorized_keys file. So it seems both attempts are tried, even if the key's not in the file. For example, if I have a single key not in the remote's authorized keys file I see two messages. Your statement says it should "avoid the cost" of the 2nd attempt, right?

Okay, this does actually seem to work with credentials Custom and No Private Key, although the UI around this could be improved.

I verified my code and agent authentication is used for both the jumphost and host when it is selected. From the log you submitted, I see that 4 keys were tried with the jumphost but none were accepted.

So this is now working. With no logout, restart of the app or anything.

My best guess is that perhaps I hadn't set the users correctly? My local username is different from the remote, is different from the gateway. It would be really useful to see the attempted username in the log...

Another logging or implementation anomaly: I did some explicit successes and failures, and for each key in the ring two different failures were logged. For example, with a single key that isn't going to be accepted, you see two failures. If the 3rd key in the ring will succeed, you see four failures before success. Not sure if it's a logging duplication, or a duplicate attempt.

[5/16/2018 11:51:30 AM] Server authenticated

[5/16/2018 11:51:30 AM] ssh_agent_get_ident_count: Answer type: 12, expected answer: 12

[5/16/2018 11:51:30 AM] ssh_userauth_request_service: Failed to request "ssh-userauth" service

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

Awesome, thank you. I'm using the same format that works with SSH command line. If RDM requires something else some inline help would be great.

The following command works just fine to escape an IPv4 environment and reach an IPv6 target:

ssh -N -p 22 user@example.com -L 127.0.0.1:2222:[2601:646:8182:7d:82:9bff:3ef2:1084]:22

However when I configure the same node and account in Remote Desktop Manager as an SSH gateway it always fails:

[5/16/2018 1:54:08 PM] Starting SSH negociation

[5/16/2018 1:54:08 PM] channel_open: Creating a channel 43 with 64000 window and 32768 max packet

[5/16/2018 1:54:08 PM] ssh_connect: Socket connecting, now waiting for the callbacks to work

[5/16/2018 1:54:08 PM] socket_callback_connected: Socket connection callback: 1 (0)

[5/16/2018 1:54:08 PM] ssh_packet_channel_open_fail: Channel opening failure: channel 43 error (1) open failed

[5/16/2018 1:54:08 PM] Unable to connect remote end of tunnel: aborting connection localhost:0 -> [2601:646:8182:7d:82:9bff:3ef2:1084]:22

[5/16/2018 1:54:08 PM] ssh_socket_exception_callback: Socket exception callback: 1 (0)

[5/16/2018 1:54:08 PM] ssh_socket_exception_callback: Socket error: disconnected

[5/16/2018 1:54:08 PM] Error connecting to server: [5/16/2018 1:54:08 PM] Socket error: disconnected[5/16/2018 1:54:08 PM] Disconnecting from SSH server

[5/16/2018 1:54:08 PM] Disconnecting from SSH server

Same problem if I use a hostname that only has an AAAA address too FYI.

Whatever is built into the product. My phrasing assumes you've got a script that handles SSH authentication to set up the tunnel.

I'm not thinking of cross platform, I'm only thinking of "I'm on a Mac and want to know what variables are available for me to use on Mac" ;)

I understand you have cross-platform complications but I have no strong opinion about that. I personally would not attempt to map back and forth, because I work with tools that do that and there's always a million problems because of mismatched expectations. Although I wouldn't mind if $VAR sourced from X on Mac and Y on Windows, they are your variables use them as see fit.

I verified my code and agent authentication is used for both the jumphost and host when it is selected. From the log you submitted, I see that 4 keys were tried with the jumphost but none were accepted.

So if the jumphost is my direct target it works fine. When it's the SSH gateway the agent auth fails.

I confirm that the socket used for the agent is logged only if agent authentication fails. Maybe it could be logged in all case, I'll check that out in my next version of the SSH protocol implementation.

I don't think that's a problem, but there's clearly a few missing linefeeds in the log when a failure occurs which would be nice to clean up ;)

[5/16/2018 11:51:31 AM] Error authenticating user on server by agent: [5/16/2018 11:51:31 AM] Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password[5/16/2018 11:51:31 AM] Tried this socket for the agent: /private/tmp/com.apple.launchd.x7q8DDm5Z1/Listeners

Would still like to see this. Would have been helpful with SSH agent auth...

It seems that SSH using the local agent is working fine (when configured in the Advanced page) but it doesn't use the agent for the SSH Gateway (Jump Host) when configured.

While you could add an option there, I suspect that someone who is using an agent will use it for both so the agent configuration should probably be assumed.

FYI, it appears to ignore the agent for jumphost configuration. When I configure an SSH jumphost, it fails and then identifies the correct agent location. So I guess that log only shows up when there's a failure.

[5/16/2018 11:51:30 AM] Starting SSH negociation

[5/16/2018 11:51:30 AM] ssh_connect: libssh 0.7.5 (c) 2003-2014 Aris Adamantiadis, Andreas Schneider, and libssh contributors. Distributed under the LGPL, please refer to COPYING file for information about your rights, using threading threads_noop

[5/16/2018 11:51:30 AM] ssh_connect: Socket connecting, now waiting for the callbacks to work

[5/16/2018 11:51:30 AM] socket_callback_connected: Socket connection callback: 1 (0)

[5/16/2018 11:51:30 AM] ssh_client_connection_callback: SSH server banner: SSH-2.0-OpenSSH_6.6.1

[5/16/2018 11:51:30 AM] ssh_analyze_banner: Analyzing banner: SSH-2.0-OpenSSH_6.6.1

[5/16/2018 11:51:30 AM] ssh_analyze_banner: We are talking to an OpenSSH client version: 6.6 (60600)

[5/16/2018 11:51:30 AM] ssh_packet_dh_reply: Received SSH_KEXDH_REPLY

[5/16/2018 11:51:30 AM] ssh_client_curve25519_reply: SSH_MSG_NEWKEYS sent

[5/16/2018 11:51:30 AM] ssh_packet_newkeys: Received SSH_MSG_NEWKEYS

[5/16/2018 11:51:30 AM] ssh_packet_newkeys: Signature verified and valid

[5/16/2018 11:51:30 AM] Server authenticated

[5/16/2018 11:51:30 AM] ssh_agent_get_ident_count: Answer type: 12, expected answer: 12

[5/16/2018 11:51:30 AM] ssh_userauth_request_service: Failed to request "ssh-userauth" service

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] ssh_packet_userauth_failure: Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

[5/16/2018 11:51:31 AM] Error authenticating user on server by agent: [5/16/2018 11:51:31 AM] Access denied. Authentication that can continue: publickey,gssapi-keyex,gssapi-with-mic,password[5/16/2018 11:51:31 AM] Tried this socket for the agent: /private/tmp/com.apple.launchd.x7q8DDm5Z1/Listeners

[5/16/2018 11:51:31 AM] Disconnecting from SSH server

[5/16/2018 11:51:31 AM] Disconnecting from SSH server

Also, the process now works for direct login but it isn't logging the environment variable:

[5/16/2018 11:30:19 AM] Starting SSH negociation

[5/16/2018 11:30:19 AM] ssh_connect: libssh 0.7.5 (c) 2003-2014 Aris Adamantiadis, Andreas Schneider, and libssh contributors. Distributed under the LGPL, please refer to COPYING file for information about your rights, using threading threads_noop

[5/16/2018 11:30:19 AM] ssh_connect: Socket connecting, now waiting for the callbacks to work

[5/16/2018 11:30:19 AM] socket_callback_connected: Socket connection callback: 1 (0)

[5/16/2018 11:30:19 AM] ssh_client_connection_callback: SSH server banner: SSH-2.0-OpenSSH_6.6.1

[5/16/2018 11:30:19 AM] ssh_analyze_banner: Analyzing banner: SSH-2.0-OpenSSH_6.6.1

[5/16/2018 11:30:19 AM] ssh_analyze_banner: We are talking to an OpenSSH client version: 6.6 (60600)

[5/16/2018 11:30:19 AM] ssh_packet_dh_reply: Received SSH_KEXDH_REPLY

[5/16/2018 11:30:19 AM] ssh_client_curve25519_reply: SSH_MSG_NEWKEYS sent

[5/16/2018 11:30:19 AM] ssh_packet_newkeys: Received SSH_MSG_NEWKEYS

[5/16/2018 11:30:19 AM] ssh_packet_newkeys: Signature verified and valid

[5/16/2018 11:30:19 AM] Server authenticated

[5/16/2018 11:30:19 AM] ssh_agent_get_ident_count: Answer type: 12, expected answer: 12

[5/16/2018 11:30:19 AM] ssh_userauth_request_service: Failed to request "ssh-userauth" service

[5/16/2018 11:30:19 AM] User authenticated successfuly by agent

[5/16/2018 11:30:19 AM] channel_open: Creating a channel 43 with 64000 window and 32768 max packet

[5/16/2018 11:30:19 AM] ssh_packet_channel_open_conf: Received a CHANNEL_OPEN_CONFIRMATION for channel 43:0

[5/16/2018 11:30:19 AM] ssh_packet_channel_open_conf: Remote window : 0, maxpacket : 32768

[5/16/2018 11:30:19 AM] channel_request: Channel request env success

[5/16/2018 11:30:19 AM] Language set to: en_US.UTF-8

[5/16/2018 11:30:19 AM] channel_request: Channel request pty-req success

[5/16/2018 11:30:19 AM] Agent forwarding channel opened

[5/16/2018 11:30:19 AM] channel_rcv_change_window: Adding 2097152 bytes to channel (43:0) (from 0 bytes)

[5/16/2018 11:30:19 AM] channel_request: Channel request shell success

[5/16/2018 11:30:19 AM] grow_window: growing window (channel 43:0) to 1280000 bytes

Hi Jo,

Here is the version in which the verbose will inform us of which socket was used by RDM: https://www.dropbox.com/s/c94tzrnaq8bw6j2/Devolutions.RemoteDesktopManager.Mac.5.3.2.1526482227.dmg?dl=0

Could you regenerate those log (you just need the verbose level 1)?

Well you're gonna laugh now, but this new version works. Yay!

The old binary recovered from Trash still doesn't work, so it's not an environment change here. There's some code difference between the two.

We'll setup an SSH server with two-factor authentication, reproduce the scenario and make a fix (adding the support for two-factors in Tunnels and Port Forward sessions at the same time).

That sounds awesome. But I think your first target should be ensuring it doesn't lock up when encountering unexpected prompts ;-) And get that test in your acceptance tests.

A possible workaround might be to allow interactive input for the gateway setup, or allow an SSH Session to be opened first and the VPN connector to use either.

So I figured out how to find out the environment variables used by the GUI, etc and it does show the right socket:

$ /bin/launchctl getenv SSH_AUTH_SOCK

/private/tmp/com.apple.launchd.x1q2dDm5Z1/Listeners

So I understand that RDM doesn't have the logic to handle this scenario correctly... but unexpected responses should not cause RDM to hang completely. This is clearly a failure of the most basic type of acceptance testing.

I sent it to you with a description.

I'm confused, as the ability to create a log file doesn't seem to exist any more. How do I send you debug logs of the transaction?

Is there a way to see what environment variables RDM sees? I'm wondering if my terminals have access to the value, but RDM doesn't because it wasn't set until after boot was complete / e.g. the GUI environment?

Might be a useful feature to allow this to be specified (I have a symlink that always points to the active socket)

Could you provide a print screen of the locked application?

Not in a public forum. Give me a place to send it which will be treated as confidential.

Now that I think of it, you're trying to do this with the SSH tunnels session. I don't think this is supported at all...

Yeah, who would have guessed that I was doing this when I said "using RDM with RDP via SSH tunnel" -- totally wasn't clear, was I?

So I was working with someone on RDM for Windows for a potential solution for his team. He was seriously not impressed by how he was required to use Task Manager to stop RDM after a session login failed. I was like "huh, never seen that on the Mac" and felt a little platform pride...

...until I went back to my desk and tried to replicate his problems on my Mac. And sure enough, same freeze required me to Force Quit RDM.

Seems the connection scripts can freeze the entire app on both platforms. That's not good.

Auth looks like this FYI:

$ ssh bastion.example.net

Password:

Enter PASSCODE: