Вход через открытый ключ 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копирует нужные ключи в нужный файл author_hosts
Что не очень помогло, но добавило к эффекту vodoo/heisenbug:
- перезагрузка машины
- перезапуск службы ssh
- возиться с глобальными опциями ssh
Я вставил полные журналы с некоторой отредактированной информацией в pastebin: стена журнала
6 ответов
Проблема была решена, она вообще не была связана с 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 на стороне сервера и посмотреть, о чем она жалуется.
Сколько времени проходит после отправки пакета publickey в ожидании ответа в случае сбоя? Если это я
Создавайте файлы, созданные в корне (не только chmod), обратно в исходную учетную запись пользователя. Вы также можете попробовать протестировать с помощью Userify, посмотреть, работает ли он и есть ли у вас открытый ключ без ошибок.
У меня часто возникали проблемы с ssh из-за того, что один и тот же MAC-адрес был связан с несколькими именами компьютеров и наоборот. Для этого есть опции командной строки для ssh. Вы также можете удалить или отредактировать файл известные хосты, чтобы устранить проблему. Не уверен, поможет ли это, но это покрывает 90% моих проблем с ssh.