- This topic has 1 reply, 2 voices, and was last updated 4 years, 11 months ago by
.
-
Posts
-
I have a user that has two Mac laptops, one on Mojave, and one with an older version of OS X. On the laptop with Mojave, he can successfully connect using the command line SSH to the system hosting NoMachine, but he can’t connect with NoMachine. On his older laptop, with the same version of the NoMachine client, he is able to use the same key to connect with both the command line ssh client AND with NoMachine. The logs of the session where the failure takes place (the important part):
May 14 17:24:23 bastion sshd[1530]: debug3: send packet: type 51 [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_request_receive entering
May 14 17:24:23 bastion sshd[1530]: debug3: monitor_read: checking request 100
May 14 17:24:23 bastion sshd[1530]: debug1: PAM: initializing for “username”
May 14 17:24:23 bastion sshd[1530]: debug1: PAM: setting PAM_RHOST to “1.2.3.4”
May 14 17:24:23 bastion sshd[1530]: debug1: PAM: setting PAM_TTY to “ssh”
May 14 17:24:23 bastion sshd[1530]: debug2: monitor_read: 100 used once, disabling now
May 14 17:24:23 bastion sshd[1530]: debug3: mm_request_receive entering
May 14 17:24:23 bastion sshd[1530]: debug3: monitor_read: checking request 4
May 14 17:24:23 bastion sshd[1530]: debug3: mm_answer_authserv: service=ssh-connection, style=, role=
May 14 17:24:23 bastion sshd[1530]: debug2: monitor_read: 4 used once, disabling now
May 14 17:24:23 bastion sshd[1530]: debug3: receive packet: type 50 [preauth]
May 14 17:24:23 bastion sshd[1530]: debug1: userauth-request for user username service ssh-connection method publickey [preauth]
May 14 17:24:23 bastion sshd[1530]: debug1: attempt 1 failures 0 [preauth]
May 14 17:24:23 bastion sshd[1530]: debug2: input_userauth_request: try method publickey [preauth]
May 14 17:24:23 bastion sshd[1530]: debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:key hash here [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_key_allowed entering [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_request_send entering: type 22 [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_request_receive_expect entering: type 23 [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_request_receive entering [preauth]
May 14 17:24:23 bastion sshd[1530]: debug3: mm_request_receive entering
May 14 17:24:23 bastion sshd[1530]: debug3: monitor_read: checking request 22
May 14 17:24:23 bastion sshd[1530]: debug3: mm_answer_keyallowed entering
May 14 17:24:23 bastion sshd[1530]: debug3: mm_answer_keyallowed: key_from_blob: 0x555a6badb5c0
May 14 17:24:23 bastion sshd[1530]: debug1: temporarily_use_uid: 1011/1011 (e=0/0)
May 14 17:24:23 bastion sshd[1530]: debug1: trying public key file /home/username/.ssh/authorized_keys
May 14 17:24:23 bastion sshd[1530]: debug1: fd 4 clearing O_NONBLOCK
May 14 17:24:23 bastion sshd[1530]: debug2: key not found
Now… in comparing the key hash between the pass and fail, it appears that the NoMachine client is sending a different hash when it fails vs. when it passes. As the certificate is the same in all cases, and only the NoMachine case is having an issue, it appears that something is causing a problem with it decoding the SSH key for authentication. Anybody have any ideas on what this could be, and how it could only impact NoMachine, and not the OpenSSH client?
Thanks for any input!
Hello ebrandsberg,
Please execute md5 command on private key files on both client NoMachine hosts, make sure that the results are exactly the same. With the release of version 7.8p1-1, openSSH introduced a new private key format (which is not currently compatible with NoMachine). We have opened a Trouble Report, which you can see here and it includes a workaround.
https://www.nomachine.com/TR02Q09140
What’s the header of private key on your Mojave host? On which host did you generate key-pair?
This topic was marked as solved, you can't post.