SSH-соединение запрашивает пароль, хотя ключ принят

Я получаю запрос на ввод пароля, хотя похоже, что мой SSH-ключ принят. Насколько я могу судить, строка «Сервер принимает ключ: pkalg ssh-rsa blen 277» в журналах ниже означает, что мой ключ принят.

Вот журналы отладки:

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/sam/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp <<HASH REDACTED>>
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/sam/.ssh/id_dsa
debug1: Trying private key: /home/sam/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1

Очень признательна за помощь, все, кого я нашел, у кого проблемы с SSH, терпят неудачу на более раннем этапе, который я вижу.

Ваш закрытый ключ наверняка не был принят, он только попытался. Существует несколько причин, по которым аутентификация на основе ключей SSH может завершиться неудачей, и ведение журнала не так уж и здорово, поэтому отладка этой конкретной проблемы - одна из моих любимых задач. Я обнаружил, что ошибка обычно является результатом одной из следующих ситуаций.

• Ваш ~/.ssh/authorized_keysфайл слишком открыт. Для вашей собственной защиты sshdпытается защитить себя от себя. Если разрешения на вашем файле авторизованных ключей, то он не пройдет аутентификацию. Беги chmod -R go-rwx ~/.ssh.
• Ваш открытый ключ ~/.ssh/authorized_keysневерен. Это может быть результатом любого количества проблем, но наиболее распространенной является проблема с копированием. Некоторые терминалы при копировании / вставке между экранами интерпретируют перенос строки как новую строку. Каждая запись в authorized_keysфайле должна быть одной строкой. Вы можете проверить это, изменив размер вашего эмулятора терминала и посмотрев, есть ли разрыв, сравнив выходные данные wc -l ~/.ssh/authorized_keysс количеством ключей, которые должны быть там, или с тем, что вам больше подходит. Просто убедитесь, что каждый ключ - одна строка, и у вас все будет хорошо.

Вставленный вами вывод ssh -v предполагает, что он пытался использовать клавишу, но это не сработало, поэтому он перешел к взаимодействию с клавиатурой.

Вы проверили журнал аутентификации на сервере, к которому подключаетесь? (например, /var/log/auth.log). Если ваша настройка на удаленном конце неверна, например, неправильные разрешения, тогда ssh -v (или -vv или -vvv) не скажет вам об этом, но будет зарегистрирован sshd.

В моем случае файл /var/log/authlogпоказал:

[ID 800047 auth.info] Authentication refused: bad ownership or modes for directory 

Я проверил правильное владение / разрешения в, .sshно у $HOMEних было 777 разрешений. Установка 755 разрешений на $HOMEразрешенном sftp для работы. Еще раз спасибо.

Если у вас есть доступ к серверу (напрямую или через другой логин), проверьте, входит ли сервер в систему (скажем) /var/log/sshdили в /var/log/secureзависимости от вашей системы

Обычно это вызвано ошибкой прав доступа к вашему ~/.ssh/authorized_keysфайлу. Убедитесь, что он не доступен для чтения всем пользователям, но важно, что он доступен для чтения пользователю (иногда пользователю службы), работающему с sshd

Важны разрешения ~/.ssh/authorized_keysв удаленном ( 600для моих систем RHEL и Solaris)

Разрешения вашего домашнего каталога в удаленном режиме важны ( 700в моих системах)

В конце sshdможет быть полезен запуск на удаленном компьютере в режиме отладки на другом порту:

sudo /usr/sbin/sshd -p 5555 -dd

5555это пример порта, вы можете изменить его. Для получения дополнительной информации в этом отношении вы можете увидеть: http://ubuntuforums.org/archive/index.php/t-2219973.html

Я обнаружил, что есть проблема, если я использую sshdсервис. Чтобы избежать этой проблемы, остановите sshdслужбу с помощью, service sshd stopа затем запустите sshdдемон из командной строки с помощью sudo /usr/sbin/sshd.

Пытаться

/sbin/restorecon -r /root/.ssh

Возможная проблема с настройкой разрешений.