ssh зависає без запрошення пароля - працює в root або інших облікових записах

У мене вхід на основі ключа ключа ssh працює нормально. Потім я змінив ім'я хоста на своєму комп’ютері, і вхід на основі ключів перестав працювати. Здавалося, має сенс. ключі, ймовірно, покладалися на моє старе ім'я хоста. Отже, я видалив усі свої ключі та всі файли в ~ / .ssh / та відновив їх (і змінив дозволені_кейди на серверах, до яких я підключаюся)

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

Більше того, коли я 'su -' викорінюватися, 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: режим 1
debug1: SSH2_MSG_NEWKEYS надіслано
debug1: очікує SSH2_MSG_NEWKEYS
debug2: set_newkeys: режим 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
написати (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
read (0x4, "\ 0", 0x4) = -1 Помилка №4

Здається, намагається щось прочитати і просто зависає на цьому. Якщо у когось є якісь пропозиції чи ідеї, я буду дуже вдячний!

Причина, коли ваш клієнт ssh зависає для вашого акаунта, але не для інших облікових записів (root), можливо, тому, що з вашим ssh-агентом щось не так. Або те, що файл 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 у файлі знаних_хостів. Просто знайдіть запис та видаліть його, після чого він повинен запросити вас знову.

З іншого боку, він повинен попереджати, коли хост не відповідає записаному.

У мене виникли проблеми, коли в OS X пошук вузла діє так, як він не працює; з'єднання просто не вичерпується, якщо очікуєте так довго, або коли з'явиться підказка, воно чекає так довго, що вам потрібно буде ввести пароль, перш ніж перервати з'єднання. Я ніколи не міг простежити це, незважаючи на те, що люди пропонують додати хост у файл хосту. Я здогадуюсь, що це був просто "збій з пошуковими запитами DNS OS X", і, як очікувалося, це буде терпіти ... якби хтось інший мав цю проблему і вирішив її, я хотів би знати про це.

Перевірте журнали на сервері. Зазвичай це в /var/log/auth.log(Debian / Ubuntu) або /var/log/secure(RedHat / CentOS). Будь-які проблеми з підключенням зазвичай реєструються там.

Переконайтесь, що / etc / hostname - це скасовується новий рядок.