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 [email protected] 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 [email protected]
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!
Odpowiedzi:
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ć:
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 .
źródło
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.
źródło
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 ...
źródło
masz wolne miejsce na dysku na swoim kliencie (i na serwerze)?
df -h
źródło
Miałem podobny problem.
Wygląda na to, że mogłem obejść ten problem, wymuszając taką nazwę użytkownika.
źródło
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.
źródło
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ć.
źródło
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.źródło
Upewnij się, że plik / etc / hostname jest zakończony znakiem nowej linii.
źródło