У меня странная проблема с открытыми ключами SSH. На сервере есть одна учетная запись, на которую я загрузил свой открытый ключ. .ssh/authorized_keys и он работает как положено (я могу войти без пароля). Затем есть учетная запись на том же сервере, где я делал то же самое (уже несколько раз), но она все еще запрашивает у меня пароль для входа.
Параметры, соответствующие этим учетным записям, следующие:
scp ~/.ssh/id_rsa.pub user@server.com:.ssh/authorized_keys несколько раз.Если я попытаюсь добавить -v к ssh-соединению, я получу следующую информацию для того, которое НЕ РАБОТАЕТ:
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /Users/pacis/.ssh/config
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/pacis/.ssh/identity type -1
debug1: identity file /Users/pacis/.ssh/id_rsa type 1
debug1: identity file /Users/pacis/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
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 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /Users/pacis/.ssh/known_hosts:40
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
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/pacis/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /Users/pacis/.ssh/identity
debug1: Trying private key: /Users/pacis/.ssh/id_dsa
debug1: Next authentication method: password
А вот то же самое, что и ожидалось:
OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /Users/pacis/.ssh/config
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /Users/pacis/.ssh/identity type -1
debug1: identity file /Users/pacis/.ssh/id_rsa type 1
debug1: identity file /Users/pacis/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
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 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.
debug1: Found key in /Users/pacis/.ssh/known_hosts:40
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
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/pacis/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session
Вот /etc/ssh/sshd_config:
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
Последняя относительная информация, которую я могу придумать, это ls -la обоих аккаунтов: домашние каталоги и .ssh каталоги.
Рабочий:
total 40
drwxr-x--- 5 user1 www-data 4096 2009-10-29 22:11 .
drwxr-x--x 6 root www-data 4096 2009-10-27 23:09 ..
....
drwx------ 2 user1 user1 4096 2009-10-23 07:20 .ssh
total 12
drwx------ 2 user1 user1 4096 2009-10-23 07:20 .
drwxr-x--- 5 user1 www-data 4096 2009-10-29 22:11 ..
-rw------- 1 user1 user1 413 2009-10-23 07:20 authorized_keys
Не рабочий:
total 68
drwxrwxr-- 6 user2 www-data 4096 2009-11-07 12:13 .
drwxr-x--x 5 root root 4096 2009-10-09 14:29 ..
....
drwx------ 2 user2 user2 4096 2009-11-07 15:52 .ssh
total 12
drwx------ 2 user2 user2 4096 2009-11-08 20:32 .
drwxrwxr-- 6 user2 www-data 4096 2009-11-07 12:13 ..
-rw------- 1 user2 user2 412 2009-11-07 09:55 authorized_keys
Я понятия не имею, почему это не работает, и я уже несколько раз проверял и перепроверил все. Что мне не хватает?
Спасибо за уделенное время.
Попробуйте удалить групповой доступ на запись в домашний каталог user2 в учетной записи, которая не работает ... Если кто-либо имеет доступ на запись, кроме учетной записи пользователя SSH, будет жаловаться. Если вы посмотрите на опубликованные списки каталогов, в рабочем каталоге есть:
drwxr-x--- 5 user1 www-data 4096 2009-10-29 22:11 ..
В нерабочем аккаунте есть:
drwxrwxr-- 6 user2 www-data 4096 2009-11-07 12:13 ..
Как я уже говорил в своих предыдущих комментариях к исходному вопросу, в 9 случаях из 10 это проблема разрешений / владения. Как только информация была предоставлена, это становится очевидным.
Глядя на один из своих аккаунтов, я получаю следующее:
$ ls -lnd .
drwxr-xr-x 14 97037 97037 4096 Nov 8 09:31 .
$ ls -lnd .ssh
drwx------ 2 97037 97037 4096 Jun 16 11:30 .ssh
$ ls -lnd .ssh/authorized_keys
-rw------- 1 97037 97037 388 Jun 16 11:30 .ssh/authorized_keys
Я могу только представить, что членство в группе www-data - это неправильный способ ограничения доступа к домашнему каталогу, позволяющий Apache обслуживать веб-страницы внутри каталога пользователей.
Кроме того, предложение Кауэра было отклонено в дисциплинарном порядке за предложение разрешений на ~/.ssh каталог, в котором указано, что все разрешения были правильными и идентичными, но предоставленное доказательство показывает обратное.
Поскольку доказательства в пудинге ... Вот журнал подключений ssh к моей учетной записи:
$ ssh -v example.com
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/jbouse/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.com [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/jbouse/.ssh/keys.d/id_rsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/id_dsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/jbouse@example type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
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 'example.com' is known and matches the RSA host key.
debug1: Found key in /home/jbouse/.ssh/known_hosts:85
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
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jbouse/.ssh/keys.d/id_rsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/id_dsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/jbouse@example
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Если я затем запустил следующее, чтобы установить разрешения для моих домашних каталогов, такие же, как у вашей учетной записи user2:
$ ls -lnd .
drwxr-xr-x 14 97037 97037 4096 Nov 8 09:31 .
$ chmod g+w .
$ ls -lnd .
drwxrwxr-x 14 97037 97037 4096 Nov 8 09:31 .
Наконец попробуйте подключиться еще раз, и я получаю следующий журнал ssh:
$ ssh -v example.com
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/jbouse/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.com [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/jbouse/.ssh/keys.d/id_rsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/id_dsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/jbouse@example type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
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 'example.com' is known and matches the RSA host key.
debug1: Found key in /home/jbouse/.ssh/known_hosts:85
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
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jbouse/.ssh/keys.d/id_rsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/id_dsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/jbouse@example
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
Когда я снова меняю права доступа, удаляя права записи для группы, я снова могу войти в учетную запись.
Проверьте разрешения для папки .ssh на сервере, на который вы пытаетесь войти. Бегать chmod -R 600 .ssh. Ssh привередлив, когда дело касается неработающих разрешений и открытых ключей.
Вы проверили всех распространенных кандидатов на сбой аутентификации ключа; следующее, что я сделаю, это увеличу уровень ведения журнала на сервере и проверю /var/log/auth.log чтобы увидеть, что он сообщает по-разному для двух логинов.
Еще стоит уточнить - на аккаунте, где он запрашивает пароль, если ввести пароль, работает ли он и позволяет войти? Если ограничения PAM запрещают вход в систему для определенной учетной записи (и вы настроили SSH для использования PAM), вы можете получить такой результат, потому что для аутентификации пароля другие ограничения PAM не проверяются до тех пор, пока вы не введете пароль.
Ваш файл «authorized_keys» может иметь другое имя. Проверьте это:
cat /etc/ssh/sshd_config | grep AuthorizedKeys
#AuthorizedKeysFile %h/.ssh/authorized_keys
Если он не отменен, проверьте разрешения для этого файла и его каталога: он должен быть доступен для чтения пользователю, в который вы входите.
Это система Debian? В таком случае у пользователя, который не работает, может быть слабый ключ.
Увидеть Вики Debian как проверить свои ключи.
Если у вас есть слабый ключ, вам придется обновить пакеты ssh в клиентской системе и повторно сгенерировать ключи для пользователя с проблемой.
ln -s authorized_keys authorized_keys2
обычно решал проблему за меня. обратите внимание, что документация IIRC препятствует этому.