Dlaczego nadal pojawia się monit o hasło z ssh z uwierzytelnianiem klucza publicznego?

Pracuję z adresu URL, który znalazłem tutaj:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certificates-ssh/

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.

Upewnij się, że uprawnienia do ~/.sshkatalogu i jego zawartości są prawidłowe. Kiedy po raz pierwszy konfigurowałem mój klucz ssh, nie miałem ~/.sshpoprawnie skonfigurowanego folderu i krzyknął na mnie.

• Twój katalog domowy ~, ~/.sshkatalog i ~/.ssh/authorized_keysplik na zdalnym komputerze muszą być zapisywane tylko przez Ciebie: rwx------i rwxr-xr-xsą w porządku, ale rwxrwx---nie są dobre¹, nawet jeśli jesteś jedynym użytkownikiem w grupie (jeśli wolisz tryby numeryczne: 700lub 755nie 775) .
  Jeśli ~/.sshlub authorized_keysjest dowiązaniem symbolicznym, sprawdzana jest ścieżka kanoniczna (z rozwiniętymi dowiązaniami symbolicznymi) .
• Twój ~/.ssh/authorized_keysplik (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.
• Twój plik klucza prywatnego (na komputerze lokalnym) musi być odczytywalny i zapisywany tylko przez Ciebie: rw-------tj 600.
• Ponadto, jeśli SELinux jest ustawiony na wymuszanie, może być konieczne uruchomienie 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.}

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 2222na serwerze (wymagana pełna ścieżka do pliku wykonywalnego sshd, which sshdmoże pomóc), a następnie nawiązanie połączenia z klientem ssh -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ś takiego

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Jeś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:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(W zależności od dystrybucji Linuksa pierwszą / ostatnią linią może być systemctl stop sshd.service/ systemctl start sshd.servicezamiast.)

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_keysplik do niezaszyfrowanego katalogu i zmienić ścieżkę ~/.ssh/config.

Skończyło się na tym, że utworzyłem /etc/ssh/usernamefolder, którego właścicielem była nazwa użytkownika, z odpowiednimi uprawnieniami i umieściłem tam authorized_keysplik. Następnie zmieniono dyrektywę AuthorizedKeysFile /etc/ssh/configna:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Umożliwia to wielu użytkownikom dostęp do ssh bez naruszania uprawnień.

Po skopiowaniu kluczy do zdalnego komputera i umieszczeniu ich w środku authorized_keysmusisz zrobić coś takiego:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Po prostu wypróbuj następujące polecenia

1. ssh-keygen

   Naciśnij klawisz Enter, aż pojawi się monit

2. ssh-copy-id -i root@ip_address

   (Raz poprosi o hasło do systemu hosta)

3. ssh root@ip_address

   Teraz powinieneś być w stanie zalogować się bez hasła

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ć.

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:

restorecon -R -v /root/.ssh

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.

ssh -vv user@host

Odkryliśmy, że domyślny klucz (id_rsa) nie został zaakceptowany i zamiast tego klient ssh zaoferował klucz pasujący do nazwy hosta klienta:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

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:

'Agent admitted failure to sign using the key'

Problem został rozwiązany przez ponowne załadowanie kluczy do agenta ssh:

ssh-add

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/

Upewnij się, że AuthorizedKeysFilewskazuje właściwą lokalizację, użyj %ujako symbolu zastępczego dla nazwy użytkownika:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

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:

service sshd reload

Dwa komentarze: to zastąpi oryginalny plik. Po prostu skopiuję wygenerowany klucz publiczny i zrobię coś takiego:

cat your_public_key.pub >> .ssh/authorized_keys

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ędzy authorized_keysi authorized_keys2, na wszelki wypadek.

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.

Natknąłem się na podobny problem i wykonałem kroki w trybie debugowania.

/usr/sbin/sshd -d

To pokazało następujący wynik

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

To było naprawdę mylące

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Pokazało, że katalog główny ma uprawnienia dla każdego. Zmieniliśmy to, aby inni nie mieli uprawnień.

[root@sys-135 ~]# chmod 750 /root

Uwierzytelnianie klucza zaczęło działać.

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.

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:

chown -R root:root /root

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.

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_keys2jako .ssh/authorized_keysnaprawiła problem.

Nie!

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:

1. OD KLIENTA - Generuj klucz: Klucz ssh-keygen -t rsa
   publiczny i prywatny ( id_rsa.pubi id_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.
   
   
2. OD KLIENTA - Skopiuj klucz publiczny na serwer : ssh-copy-id user@server
   Klucz publiczny klienta zostanie skopiowany do lokalizacji serwera ~/.ssh/authorized_keys .
   
   
3. OD KLIENTA - Połącz z serwerem:ssh user@server
   
   

Teraz, jeśli nadal nie działa po opisanych 3 krokach, spróbujmy wykonać następujące czynności:

• Sprawdź ~/sshuprawnienia do folderu na komputerze klienta i serwera .
• Sprawdź /etc/ssh/sshd_configw serwerze , aby zapewnić RSAAuthentication, PubkeyAuthenticationa UsePAMopcje nie są wyłączone, mogą być domyślnie włączone z yes.
• Jeśli wpiszesz hasło podczas generowania klucza klienta, możesz spróbować ssh-agenti ssh-adduzyskać połączenia bez hasła w sesji.
• Sprawdź zawartość /var/log/auth.logna serwerze , aby znaleźć problem dlaczego uwierzytelniania klucz jest pomijany w ogóle.

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:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

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

Te kroki powinny ci pomóc. Używam tego regularnie wśród wielu 64-bitowych maszyn Ubuntu 10.04.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

możesz umieścić to w skrypcie z kilkoma monitami i wywołać jako

script_name username remote_machine

Miał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-hdfsna /home/hdfs, przeniosłem katalog domowy do nowej lokalizacji i teraz mogę połączyć się z uwierzytelnianiem za pomocą klucza publicznego.

Po prostu miałem ten sam problem, a dla mnie rozwiązaniem było ustawić UsePAMsię no. Widzisz, nawet przy PasswordAuthenticationustawionej opcji nonadal 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 PasswordAuthenticationi UsePAMoba ustawione nona zdalnym komputerze, dostanę następujący komunikat, jeśli wejdę ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Zapewniając plik tożsamości -i, wszystko działa zgodnie z oczekiwaniami.

Tutaj może być trochę więcej informacji.

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:

# rm -rf ~/.ssh

Lokalne polecenia:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Na serwerze:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Tak było directory permission issue. Tak było na serwerze 777 I changed it back to 700. To fixedmój problem z ssh password less login failurenawet po skopiowaniu $USER/.ssh/id_rsa.pubna serwer $USER/.ssh/authorized_keys.

Jeszcze innym rozwiązaniem jest wariant @Jagadish „s odpowiedź : do stracedemona 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.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Po dowiedzeniu się, że pid wynosi 633, możemy to stracezrobić, śledząc jego dzieci:

strace -p 633 -s 4096 -f -o sux

W rezultacie wszystko, co zrobiło to sshd i jego procesy potomne, zostanie umieszczone w pliku o nazwie suxw 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:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

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/shadowmagiczne, ale ważna rzecz jest zrobiona - problem nie jest tajemniczy, ale łatwo można go debugować / przejrzeć w Google.

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

ssh-keygen -t rsa -C "your_email@example.com"

i skopiował wygenerowane klucze do komputera lokalnego i dodał nowy klucz publiczny do ~ / .ssh / uprawnionych_ kluczy na zdalnym hoście

cat id_rsa.pub >> authorized_keys

Działa teraz używanie wygenerowanych kluczy ze zdalnego połączenia z hostem. Jeśli więc inne rozwiązania zawiodą, warto spróbować.

Mój scenariusz był taki, że mam serwer NAS, na którym utworzyłem backupbotużytkownika, po utworzeniu mojego podstawowego konta, które było w stanie zalogować się, aby początkowo utworzyć backupbotużytkownika. Po majstrowaniu sudo vim /etc/ssh/sshd_configi tworzeniu backupbotużytkownika vimmożna utworzyć, przynajmniej na Ubuntu 16.04 i na podstawie twojej ~/.vimrckonfiguracji, plik wymiany pozostały po edycji sesji vim /etc/ssh/sshd_config.

Sprawdź, czy: /etc/ssh/.sshd_config.swpistnieje, a jeśli go usunie i zrestartuj sshddemona:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

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:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g 1 marca 2016