Ошибка входа в систему с открытым ключом SSH без шаблона

(ранее опубликовано в stackoverflow по ошибке)

У меня есть несколько серверов с Ubuntu 14.04.1 (sun, hyperion, ...), все из которых без проблем используют открытые ключи (OpenSSH_6.6.1, OpenSSL 1.0.1f 6 января 2014 г. на всех машинах) для rsync. Почти все...

Одно соединение выходит из строя без каких-либо изменений в конфигах или ключах. Затем я попробую заново добавить ключи, проверить ECDSA, перезагрузить / перезапустить ssh и он снова заработает. Или нет. В этом случае я просто жду случайное количество времени (от 1 часа до 3 месяцев) и делаю то же самое. На этот раз он решает проблему - на время.

Соответствующие части ssh -vvv diff:

Успешное соединение

debug1: Host 'hyperion.internal' is known and matches the ECDSA host key.
debug1: Found key in /home/bar/.ssh/known_hosts:20
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bar/.ssh/id_rsa (0x7f..),
debug2: key: /home/bar/.ssh/id_dsa ((nil)),
debug2: key: /home/bar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
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 RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp 95:...
debug3: sign_and_send_pubkey: RSA 95:...
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to hyperion.internal ([172.16.0.10]:22).

Не удалось установить соединение

debug1: Host 'hyperion.internal' is known and matches the ECDSA host key.
debug1: Found key in /home/bar/.ssh/known_hosts:20
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/bar/.ssh/id_rsa (0x7f..),
debug2: key: /home/bar/.ssh/id_dsa ((nil)),
debug2: key: /home/bar/.ssh/id_ecdsa ((nil)),
debug2: key: /home/bar/.ssh/id_ed25519 ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
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 RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/bar/.ssh/id_dsa
debug3: no such identity: /home/bar/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/bar/.ssh/id_ecdsa
debug3: no such identity: /home/bar/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/bar/.ssh/id_ed25519
debug3: no such identity: /home/bar/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

Вещи, которые я проверял несколько раз:

разрешения для .ssh / и id_rsa на всех машинах
что я использую правильные ключи
который ssh-copy-id -i /home/bar/.ssh/id_rsa europa@hyperion.internal копирует правильные ключи в правильный файл authorized_hosts

Что действительно не помогло, но добавило к эффекту vodoo / heisenbug:

перезагружаем машины
перезапуск службы ssh
возиться с глобальными параметрами ssh

Я вставил полные журналы с некоторой отредактированной информацией на pastebin: стена из бревна

Проблема решена, совсем не по ssh:

Hyperion.internal имел зашифрованный домашний адрес, поэтому поиск ключа не удался, когда он не был подключен к /home/europe.

Оглядываясь назад, это довольно очевидно, но это объясняет эффект heisenbug, заключающийся в том, что он не дает сбоев при просмотре журналов на машине (конечно, при входе в систему ...)

Надеюсь, это поможет хоть кому-то еще.

Для меня это была проблема с разрешениями, связанная с домашним каталогом. Разрешения для домашнего каталога на целевом сервере были установлены на 775. Из того, что я обнаружил, разрешения для домашнего каталога должны быть установлены на 755 или меньше. Это устанавливает его так, чтобы ни один пользователь, кроме владельца домашнего каталога, не мог иметь разрешения на запись.

debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password

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

Я бы начал с проверки системных журналов в /var/log на сервере для любых сообщений от sshd указывая, почему он отклонил попытку аутентификации.

Если у вас есть root-доступ на удаленном сервере, вы можете запустить отладочный экземпляр sshd а затем подключитесь к нему с помощью клиента. На удаленном сервере станьте root и запустите /path/to/sshd -d -p 2222. Это запустит экземпляр sshd, который прослушивает порт 2222. Он примет одно соединение и распечатает отладочную информацию на ваш терминал.

Затем на клиенте запустите ssh как обычно, но включают -p 2222 для подключения к правильному порту. Если войти в систему не удалось, проверьте вывод отладки, напечатанный сервером.

Похоже, проблема с сервером:

debug1: Offering RSA public key: /home/bar/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password

Сервер, похоже, не отправляет здесь ответ. Я бы попробовал запустить отладку до 11 на стороне сервера и посмотреть, о чем он жалуется.

Сколько времени проходит после отправки пакета открытого ключа в ожидании ответа в случае его сбоя? Если это я

Отправьте файлы, созданные root (а не только chmod), обратно в исходную учетную запись пользователя. Вы также можете попробовать протестировать с помощью Userify, посмотреть, работает ли он и есть ли у вас открытый ключ без ошибок.

У меня часто возникали проблемы с ssh из-за того, что один и тот же MAC-адрес был связан с несколькими именами компьютеров и наоборот. Для этого есть параметры командной строки ssh. Вы также можете удалить или отредактировать файл известных хостов, чтобы устранить проблему. Не уверен, что это поможет, но это покрывает 90% моих проблем с ssh.