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

469

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.

Thom
źródło
5
wynik polecenia, które podajesz ssh z flagą -v? powinien być podobny do tego pastebin.com/xxe57kxg
Rob
14
upewnij się również, że twój folder .ssh tochmod 700
Rob
8
zakładając, że masz dostęp root do serwera, /var/log/auth.logpowie ci, dlaczego logowanie się nie udaje.
UtahJarhead
5
@UtahJarhead: Na serwerze CentOS prawdopodobnie będzie /var/log/secure.
Dennis Williamson
3
Ciekawe, chmod 0700był odpowiedzią, ale kiedy zrobiłem ssh -vto 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?
void.pointer

Odpowiedzi:

556

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.

Obrabować
źródło
29
Dziękuję bardzo za wskazanie przywracania. Od jakiegoś czasu drapię się po głowie właśnie w tej kwestii.
Richard Barrell,
19
Co dziwne, miałem problemy z kontem założonym przez jego znajomego na VPS, który uruchomił autoryzację klucza publicznego. Myślałem, że wszystkie uprawnienia są prawidłowe, ale ważne jest, aby pamiętać, że /home/USERmusi to być 700lub755
Rob
2
Pamiętaj również, aby sprawdzić ustawienia właściciela i grupy, użyłem RSYNC do skopiowania pliku autoryzowanych_kluczy i nie zauważyłem, że właściciel / grupa została ustawiona na 1000 zamiast root!
nak
11
również dodaj -v do komendy ssh, aby zobaczyć, co dzieje się z tym kluczem. ssh -v user@host.
tedder42
14
chmod -R 700 ~/.sshpracował dla mnie, aby sprostać ograniczeniom tej odpowiedzi (RHEL 7)
szkocki
147

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

Tgr
źródło
5
Właśnie próbowałem tego ... i działa dobrze, gdy działam sshd -d, ale kończy się niepowodzeniem, gdy faktycznie uruchamiam service sshd start. Jestem pewien, że to proste, ale nie jestem guru Linuksa. jakieś pomysły?
N Rohler,
3
W celach informacyjnych ten post wyjaśnia rozwiązanie SELinux, które rozwiązało mój problem.
N Rohler,
2
Miałem również problemy z uruchomieniem uwierzytelniania za pomocą klucza publicznego i byłem prawie pewien, że uprawnienia do katalogu nie stanowiły problemu. Po uruchomieniu SSH w trybie debugowania szybko dowiedziałem się, że się myliłem, a problemami były uprawnienia.
ub3rst4r
3
Świetna rada, mój folder użytkownika miał złe uprawnienia.
gdfbarbosa
2
Dziękuję Ci. Ze wszystkich powodów mój użytkownik nie mógł się zalogować, ponieważ powłoka określona przez ansible (/ bin / zsh) podczas tworzenia użytkownika nie istniała. Nigdy bym tego nie zgadł.
chishaku
53

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

cee
źródło
3
Dokument
Fab V.
3
Ta odpowiedź jest istotna i pomogła mi - dla każdego, kto zastanawia się, czy to jest problem - może pojawić się komunikat „pam_ecryptfs: Passphrase file wrapped” w pliku auth.log; jakoś to nie wystarczyło, by przypomnieć sobie, że homedir został zaszyfrowany. Może się również zdarzyć, że pierwsze logowanie poprosi o hasło, kolejne sesje nie (ponieważ są odszyfrowywane, podczas gdy inne sesje są otwarte).
pacyfista
Cholera jasna, zbyt długo szukałem rozwiązania tego problemu.
h3.
33

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
gusior
źródło
1
Właściwie nie. ssh automatycznie używa ~ / .ssh / id_rsa (lub id_dsa) bez konieczności korzystania z agenta klucza.
Patrick
7
Może to być nadal przydatna rada, jeśli w ~ / .ssh / config (np. Na hoście * .mydomain.org ... IdentityFile ~ / .ssh / some_limited_use.pub - ssh-add ~ /) .ssh / some_limited_use.pub).
89c3b1b8-b1ae-11e6-b842-48d705
To rozwiązało mój problem z otrzymywaniem monitu o hasło po dodaniu klucza. Jak wskazano 89c3b1b8-b1ae-11e6-b842-48d705, powodem ręcznego uruchomienia tych poleceń była niestandardowa nazwa pliku klucza.
Михаил Лисаков
Jak wskazano powyżej w komentarzach, jeśli używasz dowolnego klucza oprócz klucza domyślnego, domyślnie nie jest on dodawany do agenta ssh. Upewnij się więc, że klucz, którego chcesz użyć, znajduje się w pęku kluczy agenta:ssh-add -L
James
30

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

Ravindra
źródło
1
Na którym serwerze?
Amalgovinus
@Amalgovinus Oczywiście uruchamiasz to na kliencie, a nie na komputerze, z którym się łączysz - nie chcesz kopii swojego klucza prywatnego na serwerze! :)
nevelis
4
Należy pamiętać, że ogólnie zezwalanie na zdalne logowanie roota nie jest zalecaną praktyką bezpieczeństwa.
arielf
26

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

Sahil
źródło
7
Mieliśmy również ten problem - 755 w domowych realiach naprawiło go
davidfrancis
Miałem uprawnienia ustawione na 777 i zostało to zignorowane, dzięki !!!
ka_lin
To samo tutaj. Dzięki. Drapałem się po głowie przez chwilę, coś się działo.
Marcin
Tak, zobacz odpowiedź tutaj, aby uzyskać więcej szczegółów unix.stackexchange.com/questions/205842/…
Tim
Może to być odpowiedź dla osób, które poprawnie wygenerowały klucz, a mimo to wciąż proszone są o podanie hasła.
Fergie
14

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
David Mackintosh
źródło
Korzystając z klienta openssh ssh root@mymachinew systemie Windows mymachinebez problemu mogłem przejść do CentOS6 , ale mam użytkownika o niższych uprawnieniach, z którego wolałbym korzystać, ale ssh regularUser@mymachinewciąż monituje mnie o hasło. myśli?
Groostav,
13

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
Joachim Nilsson
źródło
9

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/

nish
źródło
1
Jak w komentarzach do pytania sprawdź / var / log / secure lub /var/log/auth.log. W moim przypadku widzę „Użytkownik xxx z xxx niedozwolony, ponieważ nie wymieniony w AllowUsers” „input_userauth_request: niepoprawny użytkownik xxx [preauth]” (i „rexec wiersz 35: Wycofana opcja ServerKeyBits” w / var / log / messages chociaż nie wiem co to jest). Aby rozwiązać problem 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.
Gaoithe
6

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
Dziamid
źródło
4

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.

Wojtek Rzepala
źródło
Tak, zauważyłem to również w przypadku zastąpienia, ale nie miałem żadnego, więc to nie miało znaczenia. Utworzyłem dowiązanie symboliczne do autoryzowanego_kluczy2, ale to nie pomogło.
Thom
Sprawdź także uprawnienia do pliku / katalogu. Są one opisane na podanej stronie internetowej.
Wojtek Rzepala
3
twój ~ / .ssh katalog musi mieć 700 twój plik klucza prywatnego musi mieć 600 twój plik klucza publicznego musi mieć 644 twój plik auth (na pilocie) musi mieć 644
Rob
@Rob to był problem. Jeśli opublikowałbyś to jako odpowiedź, zaakceptowałbym to.
Thom
4

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.

użytkownik46932
źródło
Naprawiłem to, zmieniając pole hasła /etc/shadowdla tego użytkownika z !na *. Po tym uwierzytelnianie hasłem jest nadal niemożliwe, ale użytkownik nie jest już zablokowany.
user3132194,
4

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

Jagadish
źródło
Mam ten sam problem. Wczoraj wydałem rsync -av ./root/ root@THE_HOST:/rootpolecenie 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:/rootKomenda zmieniła właściciela i zgody /rootkatalogu zdalnego hosta. Naprawiono pozwolenie, problem rozwiązany.
LiuYan
Failed publickey for root from 135.250.24.32 port 54553 ssh2Otrzymuję tę samą wiadomość i problem, gdy zapomniałem dodać klucz pub do hosta authorized_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 <
tuk0z 17.09.16
3

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.

chinna
źródło
3

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.

Będzie
źródło
Ja też. Spójrz na wiadomości w / var / log / secure. Zobaczyłem komunikat: „Odmowa uwierzytelnienia: złe własności lub tryby katalogu” ($ HOME). Upewnij się, że nie ma dostępu do zapisu $ HOME do grupy lub innej grupy. Nigdy bym tego nie znalazł, gdybym nie miał nieautoryzowanego dostępu roota do serwera ....
SoloPilot
2

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!

Michael Scheper
źródło
Jest to również opcja konfiguracji w / etc / ssh / sshd_config, chociaż myślę, że zmieniłbym nazwę tak jak ty.
Rick Smith
2

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.
Marc
źródło
Dziękujemy za wymienienie kroków! Dotarłem do „ssh-copy-id user @ server” i zdałem sobie sprawę, że pierwotnie skopiowałem niewłaściwy klucz publiczny.
mattavatar
2

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

Czad
źródło
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
Sriharsha
źródło
Istnieje już, ssh-copy-idktóry wykonuje dwa ostatnie kroki automatycznie.
jofel
2
@ jofel pamiętaj, że w wielu systemach ssh-copy-id nie istnieje. @Sriharsha po tym mkdirteż powinieneś tam dodać, chmod 700 .ssha przy okazji nie musisz być tak gadatliwy ~/.ssh, .sshwystarczy, ponieważ polecenia i tak są wykonywane w katalogu domowym
Janos
1

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.

Andrzej Jozwik
źródło
1

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.

Marty
źródło
1

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 [email protected]        # where <user> is your username and <192.168.1.1> is the server IP
Steven C. Howell
źródło
1

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.

fastrizwaan
źródło
0

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.

Peter
źródło
0

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 "[email protected]"

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

Kovinet
źródło
0

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

rivanov
źródło