Pracuję z adresu URL, który znalazłem tutaj:
Moim klientem ssh jest Ubuntu 64-bitowy 11.10, a mój serwer to 64-bitowy Centos 6.2. Postępowałem zgodnie ze wskazówkami. Nadal pojawia się monit o hasło na ssh.
Nie jestem pewien, co dalej.
ssh
key-authentication
Thom
źródło
źródło
chmod 700
/var/log/auth.log
powie ci, dlaczego logowanie się nie udaje./var/log/secure
.0700
był odpowiedzią, ale kiedy zrobiłemssh -v
to po stronie klienta, nie wskazało to błędu związanego z tym, dlaczego klucz nie został zaakceptowany, po prostu powiedział, że próbuje hasła później, mimo że mój klient wysłał klucz publiczny. Jak oczekują od nas diagnozowania problemów bez informacji o błędach z serwera?Odpowiedzi:
Upewnij się, że uprawnienia do
~/.ssh
katalogu i jego zawartości są prawidłowe. Kiedy po raz pierwszy konfigurowałem mój klucz ssh, nie miałem~/.ssh
poprawnie skonfigurowanego folderu i krzyknął na mnie.~
,~/.ssh
katalog i~/.ssh/authorized_keys
plik na zdalnym komputerze muszą być zapisywane tylko przez Ciebie:rwx------
irwxr-xr-x
są w porządku, alerwxrwx---
nie są dobre¹, nawet jeśli jesteś jedynym użytkownikiem w grupie (jeśli wolisz tryby numeryczne:700
lub755
nie775
) .Jeśli
~/.ssh
lubauthorized_keys
jest dowiązaniem symbolicznym, sprawdzana jest ścieżka kanoniczna (z rozwiniętymi dowiązaniami symbolicznymi) .~/.ssh/authorized_keys
plik (na zdalnym komputerze) musi być czytelny (co najmniej 400), ale będziesz potrzebował go również do zapisu (600), jeśli dodasz do niego więcej kluczy.rw-------
tj600
.restorecon -R -v ~/.ssh
(patrz np. Błąd Ubuntu 965663 i raport o błędzie Debiana # 658675 ; jest to załatane w CentOS 6 ).¹ Z wyjątkiem niektórych dystrybucji (Debian i pochodne), które załatały kod, aby umożliwić zapisywanie w grupie, jeśli jesteś jedynym użytkownikiem w grupie.
źródło
/home/USER
musi to być700
lub755
ssh -v user@host
.chmod -R 700 ~/.ssh
pracował dla mnie, aby sprostać ograniczeniom tej odpowiedzi (RHEL 7)Jeśli masz uprawnienia roota do serwera, najłatwiejszym sposobem rozwiązania takich problemów jest uruchomienie sshd w trybie debugowania, poprzez wydanie czegoś
/usr/sbin/sshd -d -p 2222
na serwerze (wymagana pełna ścieżka do pliku wykonywalnego sshd,which sshd
może pomóc), a następnie nawiązanie połączenia z klientemssh -p 2222 user@host
. Zmusi to demona SSH do pozostania na pierwszym planie i wyświetlania informacji debugowania o każdym połączeniu. Poszukaj czegoś takiegoJeśli nie można użyć alternatywnego portu, możesz tymczasowo zatrzymać demona SSH i zastąpić go innym w trybie debugowania. Zatrzymanie demona SSH nie niszczy istniejących połączeń, więc można to zrobić za pośrednictwem zdalnego terminala, ale jest to nieco ryzykowne - jeśli połączenie zostanie zerwane w czasie, gdy wymiana debugowania nie jest uruchomiona, nastąpi zablokowanie komputera dopóki nie możesz go ponownie uruchomić. Wymagane polecenia:
(W zależności od dystrybucji Linuksa pierwszą / ostatnią linią może być
systemctl stop sshd.service
/systemctl start sshd.service
zamiast.)źródło
sshd -d
, ale kończy się niepowodzeniem, gdy faktycznie uruchamiamservice sshd start
. Jestem pewien, że to proste, ale nie jestem guru Linuksa. jakieś pomysły?Czy twój katalog domowy jest zaszyfrowany? Jeśli tak, podczas pierwszej sesji ssh będziesz musiał podać hasło. Druga sesja ssh na tym samym serwerze działa z kluczem autoryzacji. W takim przypadku możesz przenieść swój
authorized_keys
plik do niezaszyfrowanego katalogu i zmienić ścieżkę~/.ssh/config
.Skończyło się na tym, że utworzyłem
/etc/ssh/username
folder, którego właścicielem była nazwa użytkownika, z odpowiednimi uprawnieniami i umieściłem tamauthorized_keys
plik. Następnie zmieniono dyrektywę AuthorizedKeysFile/etc/ssh/config
na:Umożliwia to wielu użytkownikom dostęp do ssh bez naruszania uprawnień.
źródło
Po skopiowaniu kluczy do zdalnego komputera i umieszczeniu ich w środku
authorized_keys
musisz zrobić coś takiego:źródło
ssh-add -L
Po prostu wypróbuj następujące polecenia
ssh-keygen
Naciśnij klawisz Enter, aż pojawi się monit
ssh-copy-id -i root@ip_address
(Raz poprosi o hasło do systemu hosta)
ssh root@ip_address
Teraz powinieneś być w stanie zalogować się bez hasła
źródło
Stawiłem czoła wyzwaniom, gdy katalog domowy na pilocie nie ma odpowiednich uprawnień. W moim przypadku użytkownik zmienił katalog domowy na 777, aby uzyskać dostęp lokalny w zespole. Maszyna nie mogła się już połączyć za pomocą kluczy SSH. Zmieniłem uprawnienie na 744 i znów zaczęło działać.
źródło
SELinux na RedHat / CentOS 6 ma problem z uwierzytelnianiem klucza publicznego , prawdopodobnie po utworzeniu niektórych plików selinux nie ustawia poprawnie ACL-ów.
Aby ręcznie naprawić listy ACL SElinux dla użytkownika root:
źródło
ssh root@mymachine
w systemie Windowsmymachine
bez problemu mogłem przejść do CentOS6 , ale mam użytkownika o niższych uprawnieniach, z którego wolałbym korzystać, alessh regularUser@mymachine
wciąż monituje mnie o hasło. myśli?Napotkaliśmy ten sam problem i postępowaliśmy zgodnie z instrukcjami w odpowiedzi. Ale nadal nie działało to dla nas. Nasz problem polegał na tym, że logowanie działało z jednego klienta, ale nie z drugiego (katalog .ssh został zamontowany w systemie plików NFS i obaj klienci używali tych samych kluczy).
Musieliśmy więc pójść o krok dalej. Uruchamiając komendę ssh w trybie pełnym, otrzymujesz wiele informacji.
Odkryliśmy, że domyślny klucz (id_rsa) nie został zaakceptowany i zamiast tego klient ssh zaoferował klucz pasujący do nazwy hosta klienta:
Oczywiście to nie zadziała od żadnego innego klienta.
Tak więc rozwiązaniem w naszym przypadku było przełączenie domyślnego klucza rsa na ten, który zawierał użytkownik @ myclient. Gdy klucz jest domyślny, sprawdzanie nazwy klienta nie jest sprawdzane.
Potem, po zmianie, natrafiliśmy na inny problem. Najwyraźniej klucze są buforowane w lokalnym agencie ssh, aw dzienniku debugowania wystąpił następujący błąd:
Problem został rozwiązany przez ponowne załadowanie kluczy do agenta ssh:
źródło
Byłby to brak konfiguracji SSH po stronie serwera. Plik sshd_config po stronie serwera musi zostać poddany edycji. Znajduje się w
/etc/ssh/sshd_config
. W tym pliku zmień zmienne„tak” na „nie” dla ChallengeResponseAuthentication, PasswordAuthentication, UsePAM
„nie” na „tak” dla uwierzytelnienia Pubkey
Na podstawie http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/
źródło
vi /etc/ssh/sshd_config
, dodaj użytkownika xxx do listy AllowUsers,service sshd restart
*** UWAGA: ponowne uruchomienie usługi sshd ze złym sshd_config może zablokować cię po wyjęciu z pudełka !? *** To się udało.Upewnij się, że
AuthorizedKeysFile
wskazuje właściwą lokalizację, użyj%u
jako symbolu zastępczego dla nazwy użytkownika:Może być tak, że musisz odkomentować linię:
AuthorizedKeysFile .ssh / Author_keys
Pamiętaj, że musisz ponownie załadować usługę ssh, aby nastąpiły zmiany:
źródło
Dwa komentarze: to zastąpi oryginalny plik. Po prostu skopiuję wygenerowany klucz publiczny i zrobię coś takiego:
Spowoduje to dołączenie klucza, którego chcesz użyć, do wcześniej istniejącej listy kluczy. Ponadto niektóre systemy używają tego pliku
authorized_keys2
, więc dobrym pomysłem jest utworzenie twardego łącza wskazującego pomiędzyauthorized_keys
iauthorized_keys2
, na wszelki wypadek.źródło
Moim rozwiązaniem było zablokowanie konta. Wiadomość znaleziona w / var / log / secure: Użytkownik nie jest dozwolony, ponieważ konto jest zablokowane Rozwiązanie: podaj użytkownikowi nowe hasło.
źródło
/etc/shadow
dla tego użytkownika z!
na*
. Po tym uwierzytelnianie hasłem jest nadal niemożliwe, ale użytkownik nie jest już zablokowany.Natknąłem się na podobny problem i wykonałem kroki w trybie debugowania.
To pokazało następujący wynik
To było naprawdę mylące
Pokazało, że katalog główny ma uprawnienia dla każdego. Zmieniliśmy to, aby inni nie mieli uprawnień.
Uwierzytelnianie klucza zaczęło działać.
źródło
rsync -av ./root/ root@THE_HOST:/root
polecenie przesłania niektórych plików z mojego lokalnego katalogu roboczego, a następnie ten problem występuje (w rzeczywistości na początku go nie zauważyłem. Po tym, jak zadania crona na innych hostach zawiodły następnego dnia rano, zacząłem kopać przyczynę) .rsync -av ./root/ root@THE_HOST:/root
Komenda zmieniła właściciela i zgody/root
katalogu zdalnego hosta. Naprawiono pozwolenie, problem rozwiązany.Failed publickey for root from 135.250.24.32 port 54553 ssh2
Otrzymuję tę samą wiadomość i problem, gdy zapomniałem dodać klucz pub do hostaauthorized_keys
. Dodając ten komentarz, jak w moim przypadku, zwykle zdaję sobie sprawę z mojego błędu po sprawdzeniu debugowania i wszystkich uprawnień oraz plików konfiguracyjnych #: o <W pliku / etc / selinux / config zmiana SELINUX na wyłączone z wymuszania sprawiła, że ssh bez hasła działał z powodzeniem.
Wcześniej mogę to zrobić w jedną stronę. Teraz z obu stron jestem w stanie wykonać ssh bez hasła.
źródło
Jedną z rzeczy, które pomyliłem, była własność mojego katalogu domowego w systemie serwera. System serwera został ustawiony na domyślny: domyślny, więc I:
I zadziałało. Innym tanim obejściem jest wyłączenie StrictModes: StirctModes no. w sshd_config. To przynajmniej powie ci, czy protokoły wymiany kluczy i połączenia są dobre. Następnie możesz udać się na polowanie na złe uprawnienia.
źródło
Dla mnie rozwiązanie było przeciwne do rozwiązania Wojtka Rzepali : nie zauważyłem, że nadal używam
authorized_keys2
, co jest przestarzałe . Moja konfiguracja ssh przestała działać w pewnym momencie, prawdopodobnie po aktualizacji serwera. Zmiana nazwy.ssh/authorized_keys2
jako.ssh/authorized_keys
naprawiła problem.Nie!
źródło
W przeszłości natknąłem się na tutoriale opisujące, jak osiągnąć konfigurację bez haseł ssh, ale niektóre są niestety błędne.
Zacznijmy od nowa i sprawdzaj każdy krok:
ssh-keygen -t rsa
publiczny i prywatny (
id_rsa.pub
iid_rsa
) zostaną automatycznie zapisane w~/.ssh/
katalogu.Konfiguracja będzie łatwiejsza, jeśli użyjesz pustego hasła. Jeśli nie chcesz tego zrobić, postępuj zgodnie z tym przewodnikiem, ale także sprawdź punktator poniżej.
ssh-copy-id user@server
Klucz publiczny klienta zostanie skopiowany do lokalizacji serwera
~/.ssh/authorized_keys
.ssh user@server
Teraz, jeśli nadal nie działa po opisanych 3 krokach, spróbujmy wykonać następujące czynności:
~/ssh
uprawnienia do folderu na komputerze klienta i serwera ./etc/ssh/sshd_config
w serwerze , aby zapewnićRSAAuthentication
,PubkeyAuthentication
aUsePAM
opcje nie są wyłączone, mogą być domyślnie włączone zyes
.ssh-agent
issh-add
uzyskać połączenia bez hasła w sesji./var/log/auth.log
na serwerze , aby znaleźć problem dlaczego uwierzytelniania klucz jest pomijany w ogóle.źródło
Miałem dokładnie ten sam problem z połączeniem PuTTY z komputerem Ubuntu 16.04. To było zagadkowe, ponieważ program pscp PuTTY działał dobrze z tym samym kluczem (i ten sam klucz działał w PuTTY, aby połączyć się z innym hostem).
Dzięki cennemu komentarzowi z @UtahJarhead sprawdziłem mój plik /var/log/auth.log i znalazłem:
Okazuje się, że nowsze wersje OpenSSH domyślnie nie akceptują kluczy DSA. Gdy zmieniłem klucz DSA na klucz RSA, wszystko działało dobrze.
Inne podejście: w tym pytaniu omówiono, jak skonfigurować serwer SSH do akceptowania kluczy DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1
źródło
Te kroki powinny ci pomóc. Używam tego regularnie wśród wielu 64-bitowych maszyn Ubuntu 10.04.
możesz umieścić to w skrypcie z kilkoma monitami i wywołać jako
źródło
ssh-copy-id
który wykonuje dwa ostatnie kroki automatycznie.mkdir
też powinieneś tam dodać,chmod 700 .ssh
a przy okazji nie musisz być tak gadatliwy~/.ssh
,.ssh
wystarczy, ponieważ polecenia i tak są wykonywane w katalogu domowymMiałem podobny problem z ssh. W moim przypadku problem polegał na tym, że zainstalowałem cloudera hadoop (z rpm na centos 6) i utworzyłem hdfs użytkownika z katalogiem domowym
/var/lib/hadoop-hdfs
(niestandardowy/home/hdfs
).Zmieniłem / etc / passwd
/var/lib/hadoop-hdfs
na/home/hdfs
, przeniosłem katalog domowy do nowej lokalizacji i teraz mogę połączyć się z uwierzytelnianiem za pomocą klucza publicznego.źródło
Po prostu miałem ten sam problem, a dla mnie rozwiązaniem było ustawić
UsePAM
sięno
. Widzisz, nawet przyPasswordAuthentication
ustawionej opcjino
nadal będziesz otrzymywaćkeyboard-interactive
, aw moim przypadku mój lokalny program ssh z jakiegoś powodu nadal domyślnie się do tego dostosowuje .Dodatkowe tło, aby pomóc każdemu w tej samej sytuacji: Łączę się z hosta z Dropbear do jednego z OpenSSH. Z
PasswordAuthentication
iUsePAM
oba ustawioneno
na zdalnym komputerze, dostanę następujący komunikat, jeśli wejdęssh user@server
:Zapewniając plik tożsamości
-i
, wszystko działa zgodnie z oczekiwaniami.Tutaj może być trochę więcej informacji.
źródło
Po sprawdzeniu uprawnień i wypróbowaniu kilku innych wymienionych tutaj rozwiązań w końcu usunąłem katalog ssh na serwerze, ponownie konfigurując mój klucz publiczny.
Polecenia serwera:
Lokalne polecenia:
źródło
Na serwerze:
Tak było
directory permission issue
. Tak było na serwerze 777I changed it back to 700
. Tofixed
mój problem zssh password less login failure
nawet po skopiowaniu$USER/.ssh/id_rsa.pub
na serwer$USER/.ssh/authorized_keys
.źródło
Jeszcze innym rozwiązaniem jest wariant @Jagadish „s odpowiedź : do
strace
demona ssh.Ma to tę istotną zaletę, że nie musimy zatrzymywać sshd, co może skutkować całkowitą blokadą, jeśli coś pójdzie nie tak.
Najpierw znajdujemy pid głównego procesu sshd. Tutaj możemy to zobaczyć wykonując
pstree -pa|less
.Po dowiedzeniu się, że pid wynosi 633, możemy to
strace
zrobić, śledząc jego dzieci:W rezultacie wszystko, co zrobiło to sshd i jego procesy potomne, zostanie umieszczone w pliku o nazwie
sux
w katalogu lokalnym.Następnie odtwórz problem.
Będzie miał ogromną listę dzienników połączeń jądra, co jest dla nas w większości niezrozumiałe / nieistotne, ale nie wszędzie. W moim przypadku ważne było to:
Oznaczało to, że sshd próbował zalogować komunikat Użytkownik cica nie jest dozwolony, ponieważ konto jest zablokowane - to tylko nie mogło, ponieważ logowanie nie jest do tego wystarczające. Ale już wiemy, że klucz pub został odrzucony, ponieważ konto zostało zablokowane.
To jeszcze nie jest rozwiązanie - teraz musimy google, co w przypadku sshd oznacza „zablokowane konto”. Najprawdopodobniej będzie to trochę banalne
/etc/passwd
,/etc/shadow
magiczne, ale ważna rzecz jest zrobiona - problem nie jest tajemniczy, ale łatwo można go debugować / przejrzeć w Google.źródło
W moim przypadku miałem wszystkie uprawnienia i nawet kiedy uruchomiłem ssh z flagą -vvv, nie mogłem ustalić, na czym polega problem.
Wygenerowałem więc nowy certyfikat na zdalnym hoście
i skopiował wygenerowane klucze do komputera lokalnego i dodał nowy klucz publiczny do ~ / .ssh / uprawnionych_ kluczy na zdalnym hoście
Działa teraz używanie wygenerowanych kluczy ze zdalnego połączenia z hostem. Jeśli więc inne rozwiązania zawiodą, warto spróbować.
źródło
Mój scenariusz był taki, że mam serwer NAS, na którym utworzyłem
backupbot
użytkownika, po utworzeniu mojego podstawowego konta, które było w stanie zalogować się, aby początkowo utworzyćbackupbot
użytkownika. Po majstrowaniusudo vim /etc/ssh/sshd_config
i tworzeniubackupbot
użytkownikavim
można utworzyć, przynajmniej na Ubuntu 16.04 i na podstawie twojej~/.vimrc
konfiguracji, plik wymiany pozostały po edycji sesji vim/etc/ssh/sshd_config
.Sprawdź, czy:
/etc/ssh/.sshd_config.swp
istnieje, a jeśli go usunie i zrestartujsshd
demona:To magicznie rozwiązało mój problem. Wcześniej sprawdziłem wszystkie moje uprawnienia, a nawet odciski palców RSA kluczy publicznych i prywatnych. To dziwne i prawdopodobnie błąd
sshd
, szczególnie w tej wersji:źródło