ssh висит без запроса пароля - работает в root или других аккаунтах

У меня был SSH ключ на основе входа работает нормально. Затем я изменил имя хоста на моем компьютере, и логин на основе ключей перестал работать. Казалось бы, имеет смысл. ключи, вероятно, полагались на мое старое имя хоста. Итак, я удалил все свои ключи и все файлы в ~ / .ssh / и восстановил их (и изменил author_keys на серверах, к которым я подключаюсь)

Теперь, всякий раз, когда я пытаюсь выполнить ssh, он просто зависает без запроса пароля, независимо от того, где я пытаюсь подключиться по ssh - даже на серверах, где у меня не настроен вход на основе ключа. В .ssh / config ничего нет.

Более того, когда я 'su -' для root, ssh работает отлично. нет проблем вообще. Это происходит только в моей учетной записи.

Ниже приведена некоторая отладочная информация из ssh

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 марта 2009 г.
debug1: чтение данных конфигурации /Users/myname/.ssh/config
debug1: чтение данных конфигурации / usr / etc / ssh_config
......
debug1: хост «myremoteserver.com» известен и соответствует ключу хоста RSA.
debug1: найден ключ в /Users/myname/.ssh/known_hosts:1
debug2: набор битов: 512/1024
debug1: ssh_rsa_verify: подпись верна
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: отправлено сообщение SSH2_MSG_NEWKEYS
debug1: ожидается SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS получено
debug1: отправлено сообщение SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT получено

А то тут просто висит .....

Вот вывод dtruss (как strace, но для OSX) ближе к концу, где он висит: sudo dtruss ssh -vv mylogin@myremoteserver.com

выберите (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
читать (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
соединить (0x4, 0xBFFFEEA2, 0x6A) = 0 0
запись (0x4, "\ 0", 0x4) = 4 0
запись (0x4, "\ v5 \ 004 \ 0", 0x1) = 1 0
читать (0x4, "\ 0", 0x4) = -1 Err # 4

Кажется, он пытается что-то прочесть и просто висит на этом. Если у кого-то есть предложения или идеи, буду очень признателен!

Причина, по которой ваш ssh-клиент зависает для вашей учетной записи, но не для других учетных записей (root), возможно, в том, что с вашим ssh-agent что-то не так. Либо ssh-agentон не работает, либо его конфигурация неверна.

Чтобы получить подтверждение этого, вы можете попробовать следующее:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

Если вас затем попросят ввести пароль для вашего ssh_key, это означает, что у вас есть проблема с вашим ssh-agent.

Смотрите также мой пост по этому связанному вопросу .

Могу ли я заинтересовать вас обратным DNS?

По сути, клиент выполняет обратный DNS на сервере или наоборот.

Я предлагаю тест:

Отключите поиск DNS на сервере, отредактировав / etc / ssh / sshd_config и убедившись, что для «UseDNS» установлено значение «no».

Запустите «service ssh reload» (или что-то еще, что заставляет вашего ssh-демона перечитать конфигурацию), затем повторите попытку.

Кстати, это не значит, что вы наконец-то подскажете вам после длительного периода времени, не так ли?

Еще одна вещь, которую вы можете проверить, это просмотреть содержимое / etc / hosts на сервере, чтобы убедиться, что в этом нет ничего плохого.

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

у вас есть свободное дисковое пространство на вашем клиенте (и на вашем сервере)?

дф-ч

У меня была аналогичная проблема.

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 завершен символом новой строки.