Назад | Перейти на главную страницу

тот же ключ ssh rsa не работает в Ubuntu (WSL), а в RHEL7 он работает

Я пытаюсь подключиться с Ubuntu (WLS) к серверу RHEL7 с помощью ключа ssh RSA. И не работает, пока тем же ключ при использовании с другого хоста RHEL7 работает.

Из 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

То же самое от 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).

Возможно ли, что Ubuntu делает что-то безопасное со своим ssh, чтобы он больше не мог подключаться к RHEL? Нечто подобное я видел более 20 лет назад в AIX (но это было вызвано ошибкой в ​​gcc).

В вашем сообщении говорится, что вы используете один и тот же ключ, но в журналах указано, что вы использовали два разных ключа для каждой попытки подключения.

Успешный ключ от вашего клиента RHEL, согласно журналам, RSA SHA256:Rm7/A+A+sNr/1jeSVOe29DKa/F+eWOCGf+zba8LIy1s. В то время как отказавший ключ от вашего клиента Ubuntu WSL, согласно журналам, RSA SHA256:KNOpLJ8hyXysUkO9PlVuBap/YpcIB67D9dxBBOKy0bo. Как видите, на самом деле вы не используете один и тот же ключ.

Конечно, вы в любом случае не должны использовать один и тот же ключ между системами, а должны использовать разные ключи, оба из которых авторизованы на сервере. authorized_keys файл.