ssh zawiesza się bez pytania o hasło - działa na kontach root lub innych kontach

Miałem logowanie oparte na kluczu ssh działa poprawnie. Następnie zmieniłem nazwę hosta na moim komputerze i logowanie oparte na kluczach przestało działać. Wydawało się, że ma to sens. klucze prawdopodobnie polegały na mojej starej nazwie hosta. Więc usunąłem wszystkie moje klucze i wszystkie pliki z ~ / .ssh / i ponownie je wygenerowałem (i zmieniłem klucze autoryzowane na serwerach, z którymi się łączę)

Teraz, za każdym razem, gdy próbuję ssh, po prostu zawiesza się bez pytania o hasło, bez względu na to, gdzie próbuję ssh - nawet serwery, na których nie mam skonfigurowanego logowania opartego na kluczu. Nie ma nic w .ssh / config.

Ponadto, kiedy „su -” do rootowania, ssh działa idealnie. żadnych problemów. Dzieje się tak tylko na moim koncie użytkownika.

Poniżej znajduje się kilka informacji o debugowaniu z ssh

ssh -vv mylogin@myremoteserver.com
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 marca 2009
debug1: odczyt danych konfiguracyjnych /Users/myname/.ssh/config
debug1: odczyt danych konfiguracyjnych / usr / etc / ssh_config
......
debug1: Host „myremoteserver.com” jest znany i pasuje do klucza hosta RSA.
debug1: Znaleziono klucz w /Users/myname/.ssh/known_hosts:1
debug2: zestaw bitów: 512/1024
debug1: ssh_rsa_verify: poprawny podpis
debug2: kex_derive_keys
debug2: set_newkeys: tryb 1
debug1: wysłano SSH2_MSG_NEWKEYS
debug1: oczekiwanie SSH2_MSG_NEWKEYS
debug2: set_newkeys: tryb 0
debug1: odebrano SSH2_MSG_NEWKEYS
debug1: wysłano SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: otrzymano SSH2_MSG_SERVICE_ACCEPT

A potem po prostu wisi tutaj .....

Oto wyjście dtruss (jak strace, ale dla OSX) pod koniec, w którym się zawiesza: sudo dtruss ssh -vv mylogin@myremoteserver.com

wybierz (0x4, 0x508200, 0x0, 0x0, 0x0) = 1 0
czytać (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
połącz (0x4, 0xBFFFEEA2, 0x6A) = 0 0
zapis (0x4, „\ 0”, 0x4) = 4 0
zapis (0x4, „\ v5 \ 004 \ 0”, 0x1) = 1 0
odczyt (0x4, „\ 0”, 0x4) = -1 Err # 4

Wygląda na to, że próbuje coś przeczytać i po prostu się na tym opiera. Jeśli ktoś ma jakieś sugestie lub pomysły, byłbym bardzo wdzięczny!

Powodem, dla którego twój klient ssh zawiesza się na twoim koncie, ale nie na innych kontach (root), jest prawdopodobnie dlatego, że coś jest nie tak z twoim agentem ssh. Albo ssh-agentnie działa, albo jego konfiguracja jest w jakiś sposób nieprawidłowa.

Aby to potwierdzić, możesz spróbować:

unset SSH_AUTH_SOCK
ssh mylogin@myremoteserver.com

Jeśli następnie zostaniesz poproszony o wpisanie hasła do klucza ssh_key, oznacza to, że masz problem ze swoim agentem ssh.

Zobacz także mój post na to powiązane pytanie .

Czy mogę Cię zainteresować zwrotnym DNS?

Zasadniczo klient robi odwrotny DNS na serwerze lub odwrotnie.

Proponuję test:

Wyłącz wyszukiwanie DNS na serwerze, edytując / etc / ssh / sshd_config i upewniając się, że „UseDNS” jest ustawiony na „nie”.

Uruchom „service ssh reload” (lub cokolwiek, co spowoduje, że demon ssh ponownie przeczyta konfigurację), a następnie spróbuj ponownie.

Nawiasem mówiąc, nie jest tak, że w końcu po długim okresie czasu pojawia się monit, prawda?

Inną rzeczą, którą możesz sprawdzić, jest sprawdzenie zawartości / etc / hosts na serwerze, aby upewnić się, że nie ma w tym nic złego.

Sprawdź uprawnienia do katalogu ~ / .ssh i zawartych w nim plików. Domyślna umask może być zbyt liberalna, a podczas odtwarzania plików możesz przypadkowo nadać im nieprawidłowe uprawnienia. Sam byłem przez to palony kilka razy. Żaden z używanych przeze mnie klientów (lub serwerów) ssh nigdy nie dał użytecznego komunikatu o błędzie na ten temat ...

masz wolne miejsce na dysku na swoim kliencie (i na serwerze)?

df -h

Miałem podobny problem.

ssh domain.ip:user.name

Wygląda na to, że mogłem obejść ten problem, wymuszając taką nazwę użytkownika.

ssh -v domain.ip -l user.name

Dla mnie aktualizacja do systemu Snow Leopard rozwiązała ten problem. Myślę, że to było związane z błędem w OSX.

Jeśli jest to spowodowane zapisanym kluczem, powinieneś być w stanie usunąć go z katalogu ~ / .ssh w pliku znanego_hosta. Po prostu znajdź pozycję i usuń ją, a następnie wyświetli się monit

Z drugiej strony powinien ostrzegać, gdy host nie pasuje do tego, co zostało nagrane.

Miałem problemy z tym, że w OS X wyszukiwanie nazwy hosta działa tak, jakby się nie udawało; połączenie przekroczyło limit czasu oczekiwania na tak długo lub gdy pojawi się monit, czekało tak długo, że masz około dziesięciu sekund na wprowadzenie hasła przed zerwaniem połączenia. Nigdy nie udało mi się go prześledzić, mimo że ludzie sugerowali dodanie danego hosta do pliku hosta. Wydaje mi się, że była to tylko „usterka związana z wyszukiwaniem DNS OS X” i oczekiwano, że będzie tolerowana ... jeśli ktoś inny miałby ten problem i rozwiązał go, chciałbym o tym wiedzieć.

Sprawdź dzienniki na serwerze. Zwykle jest w /var/log/auth.log(Debian / Ubuntu) lub /var/log/secure(RedHat / CentOS). Wszelkie problemy z połączeniem są zwykle tam rejestrowane.

Upewnij się, że plik / etc / hostname jest zakończony znakiem nowej linii.