Проблемы с ssh и authorized_keys

Я перехожу по ssh с server1 на server2. Я создал файлы id_rsa и id_rsa.pub. Если я использую ssh для mike @ server2, он работает нормально, но ssh для john @ server2 не работает без пароля. Оба домашних каталога mike и john содержат ".ssh", который является chmod 700, и эта папка содержит "authorized_keys", содержащий только содержимое файла id_rsa.pub, сгенерированного ранее (и это chmod 600). Содержание обоих одинаковое.

Сервер 1: Linux x86_64 x86_64 x86_64 GNU / Linux

Сервер 2: AIX 5.3.0.0 64-разрядная.

Команда 1, пользователь Майк (работает без пароля): ssh -v -n -o StrictHostKeychecking=no -o NumberOfPasswordPrompts=0 mike@server2 echo Hello

~ drwx------ 7 mike mike 4096 Jan 19 2011 .

~ / .ssh drwx------ 2 mike mike 256 Nov 28 16:39 .ssh

~ / .ssh / authorized_keys -rw------- 1 mike mike 823 Apr 06 11:56 .ssh/authorized_keys

Команда 2, пользователь Джон (требуется пароль) ssh -v -n -o StrictHostKeychecking=no -o NumberOfPasswordPrompts=0 john@server2 echo Hello

~ drwx------ 12 john jgroup 4096 Apr 06 23:13 .

~ / .ssh drwx------ 2 john jgroup 256 Apr 06 23:56 .ssh

~ / .ssh / authorized_keys -rw------- 1 john jgroup 414 Apr 06 11:55 .ssh/authorized_keys

ssh -v вывод из приведенной выше команды 2:

OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server2 [X.X.X.X] port 22.
debug1: Connection established.
debug1: identity file /home/will/.ssh/identity type -1
debug1: identity file /home/will/.ssh/id_rsa type 1
debug1: identity file /home/will/.ssh/id_dsa type -1
debug1: loaded 3 keys
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.0
debug1: match: OpenSSH_5.0 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/will/.ssh/known_hosts:838
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

This network/computer system is for the use of authori...
.........................................................

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/will/.ssh/identity
debug1: Offering public key: /home/will/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/will/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Next authentication method: password
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).

У кого-нибудь есть идеи, почему он будет работать с одним пользователем, а не с другим (когда оба находятся на одном сервере)?


ssh authorized-keys
person askmike1    schedule 07.04.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Распространенные причины отказа аутентификации с помощью ключей:

  • разрешения или право собственности на ~ / .ssh не установлены должным образом (я вижу, вы их проверили)
  • открытый ключ поврежден
  • открытый ключ предназначен для другого ключа, чем закрытый ключ

Также проверьте auth.log сервера.

person Michael Slade    schedule 07.04.2012
comment
Если возникла проблема с открытым / закрытым ключом, не повлияет ли это также на подключение к другому идентификатору? - person askmike1; 07.04.2012
comment
обратите внимание, что открытый ключ предназначен для другого ключа, чем закрытый ключ. Судя по размеру файлов, у вас есть еще один ключ в файле authorized_keys первой учетной записи. Возможно, этот другой ключ на самом деле используется при подключении по ssh? - person Michael Slade; 07.04.2012
comment
Я удалил другой ключ из authorized_keys микрофона, и он по-прежнему работал с этим пользователем. - person askmike1; 07.04.2012
comment
Проверка auth.log решила эту проблему для меня. Проблема заключалась в том, что ни одна из групп пользователей не указана в AllowGroups. Добавление группы в /etc/ssh/sshd_config и перезапуск sshd помогли. - person Michael Moussa; 28.08.2014

arrow_upward
0
arrow_downward

Что вы можете войти в систему, поскольку Майк - настоящий тупица. Вы можете попробовать создать authorized_keys2 файл. authorized_keys не работает во всех версиях OpenSSH.

ln -s authorized_keys authorized_keys2
person inanutshellus    schedule 26.03.2013