Serwer nadal prosi o hasło po skopiowaniu mojego klucza publicznego SSH na klucze autoryzowane


44

Mam serwer Ubuntu działający w chmurze. Utworzyłem użytkownika ( git). W folderze /home/gitutworzyłem katalog .ssh/i authorized_keysplik.

Ale kiedy umieszczam klucz publiczny SSH w authorized_keyspliku, serwer nadal pyta mnie o hasło.

Co zrobiłem źle?


Gdzie podajesz Ypur do publicznej wiadomości? w git użytkownika czy w rootie? jak do tego dostęp? jako ssh <you> @ <server> o <git> @ <server> lub root @ <server> .. sprawdź to i dodaj więcej informacji.
maniat1k

Odpowiedzi:


42

Po stronie serwera demon ssh zaloguje błędy /var/log/auth.log, więc sprawdź ten plik, aby zobaczyć, co jest zgłaszane.

Od strony klienta podczas nawiązywania połączenia możesz dodać -vflagę (lub -vvlub -vvv), aby zwiększyć poziom szczegółowości. W ten sposób możesz zidentyfikować swój problem.

Oto inne rzeczy do sprawdzenia.

  • Upewnij się, że /home/git/.ssh/authorized_keysjest własnością git.
  • Upewnij się, że /home/git/.ssh/authorized_keysma tryb 600 ( -rw-------).

Sprawdź także /etc/ssh/sshd_configplik.

  • PubkeyAuthentication powinien być ustawiony na yes
  • Istnieje również AuthorizedKeysFiledyrektywa, która określa ścieżkę, w której powinny znajdować się autoryzowane klucze. Upewnij się, że jest to komentarz lub domyślnie %h/.ssh/authorized_keys.

Dzięki! Spróbuję tych opcji i wrócę później do opinii!
Luis Dalmolin,

Co robisz, jeśli nie widzisz /var/log/auth.logpliku? Czy istnieje sposób, aby to włączyć?
Steve Robbins,

1
Dzienniki mogą znajdować się w / var / log / secure, jeśli nie masz /var/log/auth.log
CoverosGene

Głupia pomyłka, scp-ededowałem plik .pub do folderu .ssh na serwerze, z którym chciałem się połączyć. Pamiętaj, aby przenieść go do folderu autoryzowane klucze.
CenterOrbit

Musiałem także usunąć uprawnienia do zapisu grupowego z samego katalogu domowego. Następnie ponownie uruchomiłem ssh zsudo service ssh restart
Dylan Pierce

19

Upewnij się także, że katalog domowy użytkownika (w twoim przypadku / home / git) jest zapisywany tylko przez Ciebie. Miałem ten problem raz, ponieważ mój katalog domowy można było zapisać w grupie. /var/log/auth.log powiedział w nim: „Odmowa uwierzytelnienia: złe własności lub tryby dla katalogu / home / chuck”. (ma to na celu upewnienie się, że nie używa pliku autoryzowanych_kluczy, z którymi bawi się ktoś inny niż ty!)


Chociaż jest to z pewnością pomocne, myślę, że jest to raczej dodatek do odpowiedzi xeyes .
gertvdijk

1
O mój boże, wielkie dzięki! Moje oczy płonęły, ponieważ wszystkie wyszukiwania, które przeprowadziłem w Google. W końcu udało się! Dziękuję bardzo.
GTRONICK,

Człowieku dzięki! Spędziłem godziny szukając rozwiązania ... i to rozwiązało wszystkie moje problemy.
Afaria

tak. to było to. Cieszę się, że postanowiłem przeczytać następną odpowiedź w dół
Katushai,

Sprawdź także w / etc / passwd, jaki jest katalog domowy użytkownika. Mój dziwny problem polegał na tym, że nie miał standardowego
drodsou

5

Istnieją różne sposoby rozwiązania tego problemu: możesz skonfigurować sshd(po stronie serwera) lub ssh(po stronie klienta), aby nie korzystał z uwierzytelniania za pomocą hasła. Wyłączenie uwierzytelniania hasła na serwerze sprawia, że ​​serwer jest bezpieczniejszy, ale będziesz miał kłopoty, jeśli zgubisz klucz.

Aby sshustawić (po stronie klienta) za pomocą uwierzytelniania klucza publicznego, dodaj kilka opcji do sshpolecenia:

ssh -o PubkeyAuthentication=yes -o PasswordAuthentication=no -X git@server

Jeśli to zadziała, możesz ustawić tę PasswordAuthentication=noopcję na stałe w pliku konfiguracyjnym klienta ssh /etc/ssh/ssh_configdla całego systemu lub ~/.ssh/configdla konkretnego użytkownika (szczegółowe informacje, patrz man ssh_config).


1
Domyślnie wszystkie konfiguracje klienta SSH ( /etc/ssh/ssh_config) w systemach Debian / Ubuntu już preferują PubkeyAuthentication i wypróbuj je najpierw, jak zobaczysz podczas wywoływania sshw trybie pełnym.
gertvdijk

3

Czy używasz ~ / .ssh / config na swoim komputerze lokalnym? Wystąpił ten problem, gdy używam dyrektywy IdentityFile w pliku konfiguracyjnym i wskazuję klucz publiczny. Na przykład:

Host Cloud
    Hostname cloud.theclouds.com
    User git
    IdentityFile ~/.ssh/config/mykey # This is correct

    # IdentityFile ~/.ssh/config/mykey.pub # This is incorrect


1

Inną sprawą do sprawdzenia jest to, czy w twoim kluczu publicznym są dodatkowe zwroty karetki. Postępowałem zgodnie z powyższą radą, aby przejrzeć plik /var/log/auth.log i zobaczyłem błąd podczas czytania klucza. Klucz miał około dwóch linii zamiast czterech. W kluczu były dodatkowe zwroty karetki.

Korzystając z edytora vi, użyj shift-j, aby połączyć linie i usunąć dodatkowe spacje w ciągu klucza.


1
Potrójnie sprawdziłem uprawnienia i sshd_config. Uderzyłem głową o ścianę przez pół godziny. To był mój błąd! W jakiś sposób przyzwyczaiłem się do kończenia wszystkich plików, które edytuję ręcznie, dodatkowym łamaniem wiersza. Nawet z jednym kluczem i zwrotem karetki na końcu wystarczy zepsuć autoryzację.
jrhorn424,

Upewnij się, że masz także ----- END RSA PRIVATE KEY ----- bit.
tobych

1

Jeśli masz wiele kluczy prywatnych, użyj przełącznika -v w poleceniu połączenia ssh, aby sprawdzić, czy inne klucze podstawowe nie są używane do próby nawiązania połączenia. Jeśli nie są, powiedz klientowi ssh, aby używał ich za pomocą następującego polecenia:

ssh-add path/to/private/key

1

Możesz także dodać swój klucz do agenta SSH:

u@pc:~$ ssh-agent bash
u@pc:~$ ssh-add ~/.ssh/id_rsa
Enter passphrase for /home/u/.ssh/id_rsa: # ENTER YOUR PASSWORD
Identity added: /home/u/.ssh/id_rsa (/home/u/.ssh/id_rsa)

0

Możliwe, że dzwonisz

sudo git clone gituser@domain:repo.git

gdzie klawisz użytkowników root ssh nie została dodana do authorized_keyszgituser


0

Na komputerze z systemem Ubuntu 18.04.02 LTS propozycja ustawienia uprawnień ~/.sshna 600 nie działała dla mnie. Musiałem ustawić uprawnienia na 700, a potem wszystko poszło dobrze.


0

Miałem poprawne uprawnienia do katalogu .ssh / i plik autoryzowanych_kluczy, ale napotkałem ten problem z monitem o hasło z powodu innego, spowodowanego przez siebie problemu.

Użyłem podświetlenia opartego na myszy i skopiuj / wklej, aby skopiować informacje z mojego lokalnego pliku id_rsa.pub do pliku uprawnionego na serwerze. Pomyślnie skopiowano dane jako pojedynczą linię, ale tam, gdzie niepożądane spacje na końcu widocznych linii były trudne do zauważenia podczas edycji pliku za pomocą vi. Po usunięciu tych niechcianych spacji mogłem ssh w porządku.


0

Tak więc stało się dla mnie, że mam 2 maszyny wirtualne, do których mam dostęp z mojego komputera lokalnego (2 klucze id_rsa.pub i id_rsa2.pub). Zrozumiałem, że moje połączenie ssh domyślnie używa id_rsa.pub dla każdego połączenia ssh użytkownik@xx.xx.xx.xx. Rozwiązałem problem, dodając plik konfiguracyjny i określając tożsamość, która ma być używana dla każdego hosta, w następujący sposób:

vi ~/.ssh/config

Add both hostnames and their identity file as follows:

Host server1.nixcraft.com
  IdentityFile ~/Users/.ssh/id_rsa1
Host server2.nixcraft.com
  IdentityFile /backup/home/aymen/.ssh/id_rsa2
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.