Клавіші DSA / RSA працюють з Linux, але не з HP-UX


2

У мене є кріплення NFS, яке я використовую для входу на багато серверів Linux / Unix. Я створив ключ RSA та DSA без паролів за допомогою, скопіювавши файли id_rsa.pub та id_dsa.pub на авторизовані_кеї.

total 9
drwx------.  2 myusername mygroup 1024 Oct  7  2014 .
drwxr-xr-x. 16 myusername mygroup 1024 Oct  7  2014 ..
-rw-------.  1 myusername mygroup  621 Oct  7  2014 authorized_keys
-rw-------.  1 myusername mygroup     668 Oct  7  2014 id_dsa
-rw-r--r--.  1 myusername mygroup     620 Oct  7  2014 id_dsa.pub
-rw-------.  1 myusername mygroup  887 Oct  7  2014 id_rsa
-rw-r-----.  1 myusername mygroup  224 Oct  7  2014 id_rsa.pub
-rw-r--r--.  1 myusername mygroup 1276 Oct  7  2014 known_hosts

Тепер я можу увійти на інший сервер Linux без введення пароля (чудово!), Але те ж саме не працює для апаратів HP-UX. Це не тільки не спрацьовує, це заважає мені взагалі ввійти. Запит на пароль не прийме мій пароль (ні ldap, ні локальний). Ось вихід, коли я намагаюся підключитися.

[myusername@machine1 .ssh]$ ssh -vvv machine2
OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to machine2 [192.168.100.50] port 22.
debug1: Connection established.
debug1: identity file /home/mynfsmount/myusername/.ssh/identity type 0
debug3: Not a RSA1 key file /home/mynfsmount/myusername/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/mynfsmount/myusername/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /home/mynfsmount/myusername/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/mynfsmount/myusername/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9
debug1: match: OpenSSH_3.9 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug3: Wrote 792 bytes for a total of 813
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug3: Wrote 24 bytes for a total of 837
debug2: dh_gen_key: priv key bits set: 137/256
debug2: bits set: 496/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: Wrote 144 bytes for a total of 981
debug3: check_host_in_hostfile: filename /home/mynfsmount/myusername/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug3: check_host_in_hostfile: filename /home/mynfsmount/myusername/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 1
debug1: Host 'machine2' is known and matches the RSA host key.
debug1: Found key in /home/mynfsmount/myusername/.ssh/known_hosts:1
debug2: bits set: 527/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: Wrote 16 bytes for a total of 997
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug3: Wrote 48 bytes for a total of 1045
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/mynfsmount/myusername/.ssh/id_rsa (0x7f83a699deb0)
debug2: key: /home/mynfsmount/myusername/.ssh/id_dsa (0x7f83a699e540)
debug3: Wrote 64 bytes for a total of 1109
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/mynfsmount/myusername/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 240 bytes for a total of 1349
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug2: input_userauth_pk_ok: SHA1 fp 96:97:2b:5e:98:cd:2a:2e:5a:14:e1:ab:75:79:41:3f:eb:03:b1:65
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug3: Wrote 384 bytes for a total of 1733
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: /home/mynfsmount/myusername/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 528 bytes for a total of 2261
debug1: Server accepts key: pkalg ssh-dss blen 434
debug2: input_userauth_pk_ok: SHA1 fp 9b:97:04:7f:b8:09:ff:51:26:fa:d4:05:c0:e1:55:d3:2d:c0:54:60
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type DSA
debug3: Wrote 592 bytes for a total of 2853
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug3: Wrote 96 bytes for a total of 2949
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 

На цьому етапі він буде продовжувати запитувати пароль, поки він не відключить мене від багатьох помилок аутентифікації. Якщо я видаляю або порожній, .ssh/authorized_keysвін буде працювати чудово після введення мого пароля. Отже, виявляється, що машини HP-UX мають проблеми з читанням відкритого ключа в авторизованих ключах.

Що ще гірше, деякі інші співробітники здатні чудово аутентифікуватись з RSA / DSA на серверах HP-UX. Проблема в тому, що вони налаштували свою конфігурацію 8 років тому і не мають поняття, що вони робили по-іншому. Я порівняв файли та дозволи та не бачу різниці.

Ось версії ssh на двох машинах, на яких я намагався створити ключі:

OpenSSH_3.9, OpenSSL 0.9.7d 17 Mar 2004
HP-UX Secure Shell-A.03.91.002, HP-UX Secure Shell version

OpenSSH_5.3p1, OpenSSL 1.0.0-fips 29 Mar 2010

Мій syslog.log на апараті HP-UX не дає корисної інформації. Помилки, які ви бачите нижче, викликані невдалою автентифікацією PAM після того, як відкритий ключ RSA вже переданий. Я включаю лише на добру міру.

Oct  8 09:34:40 machine2 sshd[25497]: error: PAM: Success for myusername from machine1.example.com

Oct  8 09:34:40 machine2 sshd[25497]: Failed keyboard-interactive/pam for myusername from 192.168.100.90 port 59015 ssh2

Oct  8 09:34:42 machine2 sshd[25497]: error: PAM: Authentication failed for myusername from machine1.example.com

Oct  8 09:34:43 machine2 sshd[25497]: Failed password for myusername from 192.168.100.90 port 59015 ssh2

На HP-UX-машині я запустив sshd -d -p 5555і зв’язався з клієнтом за допомогою ssh -p 5555 machine2. Ось вихід. Схоже, не дає помилок.

# /usr/sbin/sshd -d -p 5555
debug1: sshd version OpenSSH_3.9 [ HP-UX Secure Shell-A.03.91.002 ]
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: rexec_argv[2]='-p'
debug1: rexec_argv[3]='5555'
debug1: Bind to port 5555 on 0.0.0.0.
Server listening on 0.0.0.0 port 5555.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8

Я здаюсь поки. Я просто поставив той самий відкритий ключ RSA від мого локального облікового запису до дозволених_кіней root, і мені вдалося увійти як кореневий бездоганно. Потім я вставив відкритий ключ RSA в авторизовані_ліки мого облікового запису, і він також працював. Проблема, як видається, виникає лише тоді, коли я сш з мого облікового запису, встановленого NFS, до мого облікового запису, встановленого NFS. Чому це мало б значення, я не знаю.


Які версії SSH використовуються для генерації ключів?
Мисливець на оленів

Я не впевнений, які версії ssh. Мені доведеться перевірити, коли я прийду на роботу в ранку. Щодо ключів rsa, я спробував обидва протоколи 1 та 2.
Jeight

Я спробував створити ключі як на машині HP-UX, так і на машині RHEL 6.4.
Jeight

Я оновив питання з версіями ssh
Jeight

1
Ах рекс. Зараз це не потрібно, але в майбутньому додайте -rтакож а так, щоб він не виконував другий виконавець, і ви отримаєте всі повідомлення про налагодження. Це все ще не може вказувати на що-небудь, крім помилки PAM, але це було б краще, ніж у предметів, які ви отримали.
BowlOfRed

Відповіді:


1

Тож відповідь ... ой відповідь.

Винувателем став файл тіньового пароля. Незважаючи на те, що у нас є LDAP, ми не використовуємо його для заміни записів у файлі passwd. Я працював над оновленням наших серверів LDAP та їх виготовленням, щоб нам не потрібні записи файлів passwd. Тож я єдиний без проходу passwd. Це, здається, працює в більшості випадків, але, мабуть, все ще є деякі помилки на апаратах HP-UX.

Коли я налагоджував проблему з аутентифікацією RSA, я додав себе до файлу passwd, але забув виконати pwconvкоманду.

Тепер мені просто потрібно знайти і виправити все, що блокує LDAP від ​​використання RSA для доступу. Йіппі! ... зітхну.


2
додавання rcommandдо облікового запису libpam_ldap у pam.conf виправило проблему повністю.
Jeight
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.