Невозможно настроить логин ssh без ввода пароля

8

Я автоматически настроил вход в систему через ssh без ввода пароля на сервер:

cd ~/.ssh

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server1

Работает на сервере.

Позже я сделал то же самое на другом сервере.

ssh-copy-id -i ~/.ssh/id_rsa.pub tim@server2

Сразу же ssh tim@server2, но это все еще требует мой пароль. Я сделал что-то неправильно? Каковы некоторые возможные причины, по которым я не был успешно настроен на втором сервере? (обратите внимание, что второй сервер работает с Kerberos и файловой системой Andrew)

$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type -1
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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: Server host key: RSA xxx
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_dsa
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:

Я попробовал метод Энтона использовать ключи Диффи-Хеллмана, но он все еще спрашивает мой пароль.

$ cd ~/.ssh
$ ssh-keygen -t dsa
$ ssh-copy-id -i ~/.ssh/id_dsa.pub tim@server2
$ ssh -v tim@server2
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to server2 [...] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: identity file /home/tim/.ssh/id_dsa type 2
debug1: identity file /home/tim/.ssh/id_dsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ecdsa type -1
debug1: identity file /home/tim/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/tim/.ssh/id_ed25519 type -1
debug1: identity file /home/tim/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<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: Server host key: RSA ...
debug1: Host 'server2' is known and matches the RSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:70
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Offering DSA public key: /home/tim/.ssh/id_dsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/tim/.ssh/id_ecdsa
debug1: Trying private key: /home/tim/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
ssh Тим
источник
Ваш домашний каталог смонтирован после входа в систему?
Муру
После каждого логина в прошлом мой дом всегда монтировался.
Тим
Да, когда вы входите в систему, вы получаете домашний каталог - но как быть до того, как вход в систему будет завершен? (Рассмотрим зашифрованные домашние каталоги или сетевой домашний каталог и т. Д.)
muru
Я слышал, server2использует файловую систему Эндрю. Означает ли это, что мой дом не подключен до завершения входа в систему? Как я могу узнать это по вашему вопросу?
Тим
Я не уверен, как работает файловая система Andrew, но если у вас есть другой логин на том же сервере, используйте его и посмотрите, можете ли вы увидеть содержимое timдомашнего каталога.
Муру

Ответы:

10

Вы упоминаете, что второй сервер использует файловую систему Andrew (AFS).

Я не работал с этим, но насколько я понимаю, AFS - это защищенная Kerberos файловая система, для работы которой требуется билет Kerberos. Это означает, что вам нужно войти в сферу Kerberos вашего сайта, чтобы иметь доступ к вашему домашнему каталогу.

Если вы входите с паролем, server2скорее всего, он настроен так, что он входит в вашу сферу Kerberos через PAM. Однако, если вы используете ключи SSH, server2вы не получите информацию, необходимую для этого, и не сможете получить доступ к своему домашнему каталогу.

К счастью, из ssh -vрезультатов вашего вопроса мы можем сделать вывод, что на вашем сервере GSSAPIвключена аутентификация. Это должно позволить вам выполнить вход без пароля, если у вас есть действительный билет Kerberos для вашей области. Сделайте следующее:

  • Войдите в систему server2и запустите klistпрограмму. Это вернет что-то вроде следующего:

    Ticket cache: FILE:/tmp/krb5cc_2000
Default principal: wouter@EXAMPLE.ORG

Valid starting     Expires            Service principal
28-05-15 15:01:31  29-05-15 01:01:31  krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
    renew until 29-05-15 15:01:28
28-05-15 15:02:04  29-05-15 01:01:31  IMAP/example.org@EXAMPLE.ORG
    renew until 29-05-15 15:01:28

    ищите строку, которая начинается с Default principal:. Он говорит вам, каков ваш принципал Kerberos (в приведенном выше примере это wouter@EXAMPLE.ORG). Запишите это. Обратите внимание, что это не адрес электронной почты, и что он чувствителен к регистру; т. е. основной заканчивается EXAMPLE.ORG, а не example.org.

  • На вашем клиентском компьютере запустите kinitс именем вашего участника (т. Е. В приведенном выше примере это будет kinit wouter@EXAMPLE.ORG). Если все пойдет хорошо, при следующем запуске klistвы увидите, что у вас есть кеш билетов на вашем локальном компьютере.
  • Если вы сейчас запустите ssh -K server2, вы сможете войти в систему, и система не должна запрашивать пароль.

Обратите внимание, что из-за того, как работает Kerberos, срок действия кэша билетов ограничен. Невозможно запросить кеш билетов со сроком действия дольше, чем настроено администратором области (обычно это что-то около 10 часов или около того). Когда срок действия вашего билета истечет, вам нужно будет kinitснова запустить его и ввести пароль еще раз.

Воутер Верхелст
источник
Спасибо. «На своей клиентской машине запустите kinit», вы имеете в виду, что мне нужно установить Kerberos на мою локальную Ubuntu?
Тим
Часть инструментов Kerberos, да. Вы найдете необходимые инструменты в krb5-userупаковке.
Воутер Верхелст
Должен ли я использовать rsa или dsa при создании открытых ключей и копировании их на сервер? (Я последовал предложению Энтона использовать dsa прямо сейчас)
Тим
Из-за AFS на сервере вы не можете использовать открытые ключи SSH, вам нужно вместо этого использовать Kerberos. Так что это не имеет значения ;-)
Wouter Verhelst
Являются ли GSSAPI, dsa и rsa всеми методами аутентификации?
Тим
5

Вы должны попытаться подключиться к server2 с помощью:

ssh -v tim@server2

и сравните это с тем же, подключение к нему server1скажет вам точно, где два сервера отличаются.

Скорее всего, есть разница в /etc/ssh/sshd_configобеих машинах. где server2или у вас ~/.sshесть проблемы с доступностью (недостаточно ограничены).

Из -vвыходных данных видно, что вы предлагаете закрытый ключ RSA для проверки (in /home/tim/.ssh/id_rsa), но похоже, что он server2поддерживает только Диффи-Хеллмана (и пытается, /home/tim/.ssh/id_dsaчто, вероятно, даже нет).

Энтон
источник
спасибо, я обновился с выходом запуска вашей команды. Не уверен, что это значит
Тим
@Tim обновил мой ответ, вам следует уточнить у администратора server2, почему он не поддерживает закрытые / открытые ключи RSA.
Антон
Помимо вопроса администратора (который я считаю невозможным внести какие-либо изменения, основываясь на моем опыте), есть ли способ работать с тем, что ожидает сервер?
Тим
@ Тим, сначала убедитесь, что ~/.sshна сервере действительно установлены ваши авторизованные ключи ( ~/.ssh/authorized_keys). Тогда вы можете попытаться ssh-keygenсоздать пару ключей diffie-hellman ssh-keygen -t dsaи скопировать их.
Антон
(1) На ~/.ssh/authorized_keysсервере есть файл . Значит ли это, что на нем установлены авторизованные ключи? (2) как скопировать сгенерированную пару ключей Диффи-Хеллмана на сервер? по scp ~/.ssh/id_dsa.pub tim@server2:~/.ssh/authorized_keys? это будет перезаписывать ~/.ssh/authorized_keysна сервере?
Тим
4

Добавьте следующую запись на клиентском компьютере, с которого вы пытаетесь выполнить ssh.

файл конфигурации: /etc/ssh/ssh_config

GSSAPIAuthentication no

После этого вы сможете ssh к машине.

Если у вас нет прав на редактирование этого файла, вы также можете добавить

Host *
  GSSAPIAuthentication no

чтобы ~/.ssh/config(создать этот файл , если он не существует)

Судхэмс Редди
источник