У меня был логин на основе ключа ssh, работающий нормально. Затем я изменил имя хоста на своем компьютере, и вход на основе ключа перестал работать. Казалось, имеет смысл. ключи, вероятно, полагались на мое старое имя хоста. Итак, я удалил все свои ключи и все файлы в ~ / .ssh / и регенерировал их (и изменил authorized_keys на серверах, к которым я подключаюсь)
Теперь, каждый раз, когда я пытаюсь использовать ssh, он просто зависает без запроса пароля, независимо от того, где я пытаюсь подключиться к ssh - даже на серверах, на которых у меня не настроен вход на основе ключа. В .ssh / config ничего нет.
Более того, когда я «su -» для получения root-прав, ssh работает отлично. вообще никаких проблем. Это происходит только в моей учетной записи.
Ниже приведена некоторая отладочная информация из ssh
ssh -vv mylogin@myremoteserver.com OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /Users/myname/.ssh/config debug1: Reading configuration data /usr/etc/ssh_config ...... debug1: Host 'myremoteserver.com' is known and matches the RSA host key. debug1: Found key in /Users/myname/.ssh/known_hosts:1 debug2: bits set: 512/1024 debug1: ssh_rsa_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: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received
А то тут просто зависает .....
Вот вывод dtruss (как strace, но для OSX) ближе к концу, где он висит: sudo dtruss ssh -vv mylogin@myremoteserver.com
select(0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
read(0x3, "$\222\351{L\363\261\25063sN\216\300@q7\203\276b\257\354\337\356\260!{\342\017\271=\222,\245\347t\006\225\257\333;\204\020]\242\005z#\0", 0x2000) = 48 0
write(0x2, "debug2: service_accept: ssh-userauth\r\n\0", 0x26) = 38 0
connect(0x4, 0xBFFFEEA2, 0x6A) = 0 0
write(0x4, "\0", 0x4) = 4 0
write(0x4, "\v5\004\0", 0x1) = 1 0
read(0x4, "\0", 0x4) = -1 Err#4
Вроде пытается что-то прочитать и просто зависает на этом. Если у кого-то есть предложения или идеи, буду очень признателен!
Причина, по которой ваш ssh-клиент зависает для вашей учетной записи, но не для других учетных записей (root), вероятно, связана с тем, что с вашим ssh-agent что-то не так. Либо это ssh-agent не работает или его конфигурация каким-то образом неверна.
Чтобы убедиться в этом, вы можете попробовать следующее:
unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com
Если затем вас попросят ввести парольную фразу в ssh_key, это означает, что у вас проблема с ssh-агентом.
Смотрите также мой пост на этот связанный вопрос.
Могу я вас заинтересовать обратным DNS?
По сути, клиент выполняет обратный DNS на сервере или наоборот.
Предлагаю тест:
Отключите поиск DNS на сервере, отредактировав / etc / ssh / sshd_config и убедившись, что для UseDNS установлено значение «no».
Запустите «service ssh reload» (или что-то еще, что заставит ваш демон ssh перечитать конфигурацию), затем повторите попытку.
Между прочим, через долгое время он, наконец, не подскажет, не так ли?
Еще вы можете проверить содержимое файла / etc / hosts на сервере, чтобы убедиться, что там все в порядке.
Проверьте права доступа к каталогу ~ / .ssh и файлам в нем. Ваша маска umask по умолчанию может быть слишком разрешающей, и когда вы воссоздали файлы, вы могли непреднамеренно дать им неправильные разрешения. Я сам несколько раз обжигался от этого. Ни один из клиентов (или серверов) ssh, которые я использовал, никогда не выдавал полезного сообщения об ошибке об этом ...
у вас есть свободное место на диске на вашем клиенте (и на вашем сервере)?
df -h
У меня была похожая проблема.
ssh domain.ip:user.name
Похоже, я мог бы обойти проблему, указав такое имя для входа.
ssh -v domain.ip -l user.name
Для меня обновление до Snow Leopard решило проблему. Итак, я думаю, это было связано с ошибкой в OSX.
Если это из-за сохраненного ключа, вы сможете удалить его из каталога ~ / .ssh в файле known_hosts. Просто найдите запись и удалите ее, и она снова появится у вас.
С другой стороны, он должен выдавать предупреждение, когда хост не соответствует записанному.
У меня были проблемы, когда в OS X поиск имени хоста работал так, как будто он не удался; соединение просто истекает из-за столь долгого ожидания, или когда появляется приглашение, оно так долго ждет, что дает вам около десяти секунд, чтобы ввести пароль, прежде чем разорвать соединение. Я так и не смог отследить это, несмотря на то, что люди предлагали добавить рассматриваемый хост в файл хоста. Я предполагаю, что это был просто «сбой при поиске в DNS OS X», и ожидалось, что его допустят ... если бы у кого-то еще была эта проблема и он решил ее, я хотел бы знать об этом.
Проверьте логи на сервере. Обычно это в /var/log/auth.log (Debian / Ubuntu) или /var/log/secure (RedHat / CentOS). Там обычно регистрируются любые проблемы с подключением.
Убедитесь, что / etc / hostname заканчивается новой строкой.