I'm trying connect from Ubuntu(WLS) to RHEL7 server using ssh RSA key. And it does not work, while the same key when used from another RHEL7 host works.
- I checked all file permissions
- There is no "from clause" in authorized keys on the other side
- I explicitly use -i option for ssh
From Ubuntu:
Ubuntu$ md5sum .ssh/id_rsa
986428c7e5882c26c9ba2b9ca403fbe3 .ssh/id_rsa
Ubuntu$ ssh -l "ansible_install" -i ~/.ssh/id_rsa -vvv -p 6000 rhel7-target
sshd debug:
debug1: userauth-request for user ansible_install service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method publickey [preauth]
debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:KNOpLJ8hyXysUkO9PlVuBap/YpcIB67D9dxBBOKy0bo [preauth]
debug3: mm_key_allowed entering [preauth]
debug3: mm_request_send entering: type 22 [preauth]
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
debug3: mm_request_receive_expect entering: type 23 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 22
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x55cc1cfca760
debug1: temporarily_use_uid: 4001/4001 (e=0/0)
debug1: trying public key file /home/ansible_install/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug2: key not found
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x55cc1cfca760 is not allowed
Failed publickey for ansible_install from 2.252.221.223 port 53431 ssh2: RSA SHA256:KNOpLJ8hyXysUkO9PlVuBap/YpcIB67D9dxBBOKy0bo
ssh debug:
debug1: identity file /home/ivabrezi/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
... (this is non-sense, the file is there)
debug2: key: /home/ivabrezi/.ssh/id_rsa (0x7fffe1905f90), explicit
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 53
debug3: input_userauth_banner
WARNING:
...
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
...
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:KNOpLJ8hyXysUkO9PlVuBap/YpcIB67D9dxBBOKy0bo /home/ivabrezi/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
The same from RHEL:
# md5sum ~/.ssh/id_rsa
986428c7e5882c26c9ba2b9ca403fbe3 /root/.ssh/id_rsa
# ssh -l "ansible_install" -i ~/.ssh/id_rsa rhel7-target
sshd debug
debug1: userauth-request for user ansible_install service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug2: input_userauth_request: try method publickey [preauth]
debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:Rm7/A+A+sNr/1jeSVOe29DKa/F+eWOCGf+zba8LIy1s [preauth]
debug3: mm_key_allowed entering [preauth]
debug3: mm_request_send entering: type 22 [preauth]
debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth]
debug3: mm_request_receive_expect entering: type 23 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 22
debug3: mm_answer_keyallowed entering
debug3: mm_answer_keyallowed: key_from_blob: 0x5607a9495770
debug1: temporarily_use_uid: 4001/4001 (e=0/0)
debug1: trying public key file /home/ansible_install/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /home/ansible_install/.ssh/authorized_keys, line 1 RSA SHA256:Rm7/A+A+sNr/1jeSVOe29DKa/F+eWOCGf+zba8LIy1s
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x5607a9495770 is allowed
ssh debug:
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:Rm7/A+A+sNr/1jeSVOe29DKa/F+eWOCGf+zba8LIy1s
debug3: sign_and_send_pubkey: RSA SHA256:Rm7/A+A+sNr/1jeSVOe29DKa/F+eWOCGf+zba8LIy1s
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Authentication succeeded (publickey).
Is it possible Ubuntu does something secure with their ssh, so it no more can connect to RHEL? Something like that I saw more than 20 years ago on AIX(but that was caused by a bug in gcc).
Your post says you are using the same key, but the logs indicate that you've used two different keys for each connection attempt.
The successful key from yuor RHEL client has, according to the logs,
RSA SHA256:Rm7/A+A+sNr/1jeSVOe29DKa/F+eWOCGf+zba8LIy1s
. While the failing key from your Ubuntu WSL client has, according to the logs,RSA SHA256:KNOpLJ8hyXysUkO9PlVuBap/YpcIB67D9dxBBOKy0bo
. As you can see, you are not actually using the same key.Of course, you shouldn't be sharing the same key between systems anyway, but using different keys, both of which are authorized in the server's
authorized_keys
file.