Вопросы Теги

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

(ранее отправленный в stackoverflow ошибкой)

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

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

Соответствующие части ssh-vvv разность:

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

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: стена журнала

5
задан 23 May 2017 в 15:41
6 ответов

Проблема решена, она вообще не была связана с ssh:

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

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

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

3
ответ дан 3 December 2019 в 01:18

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

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 на стороне сервера и посмотреть, о чем он жалуется.

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

1
ответ дан 3 December 2019 в 01:18

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

0
ответ дан 3 December 2019 в 01:18 
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

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

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

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

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

.
2
ответ дан 3 December 2019 в 01:18

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

.
0
ответ дан 3 December 2019 в 01:18

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

2
ответ дан 3 December 2019 в 01:18

Теги

Похожие вопросы