У меня запрашивают пароль, хотя похоже, что мой 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
Возможная проблема с настройкой разрешений.