ssh nie pozwala już na uwierzytelnianie kluczem publicznym

22

Mój komputer ostatnio przestał akceptować uwierzytelnianie przy użyciu klucza publicznego. Mam pulpit Ubuntu 11.04, do którego ssh z komputera z systemem Windows. Używam szpachli z przepisem. Mogę się połączyć, ale tylko z interaktywnym uwierzytelnianiem hasłem, a nie z kluczem RSA, który ustawiłem.

Już sprawdziłem, czy klucz znajduje się w ~ / .ssh / authorized_keys. Jak mogę to naprawić i co mogę sprawdzić?

    
zadawane Andrew Redd 19.10.2011, 21:27
źródło

9 odpowiedzi

28

Jeśli uwierzytelnianie za pomocą klucza publicznego nie działa: upewnij się, że po stronie serwera Twój katalog domowy ( ~ ), katalog ~/.ssh i plik ~/.ssh/authorized_keys są wszystkie możliwe do zapisu tylko przez ich właściciel . W szczególności żadna z nich nie może być zapisywalna dla grupy (nawet jeśli użytkownik jest sam w grupie). chmod 755 lub chmod 700 jest ok, chmod 770 nie jest.

Co sprawdzić, gdy coś jest nie tak:

  • Uruchom ssh -vvv , aby zobaczyć wiele wyników debugowania. Jeśli napiszesz pytanie z pytaniem, dlaczego nie możesz połączyć się z ssh, dołącz to wyjście (możesz chcieć anonimizować nazwy hosta i użytkownika).
  • Jeśli możesz, sprawdź dzienniki serwera w /var/log/auth.log .
  • Jeśli uwierzytelnianie kluczem publicznym nie działa, ponownie sprawdź uprawnienia, szczególnie bit grupy (patrz wyżej).
odpowiedział Gilles 20.10.2011, 20:00
źródło
9

Wpadłem na to samo i w końcu zorientowałem się, że to dlatego, że zaszyfrowałem mój katalog domowy. SSH nie może odczytać pliku authorized_keys, dopóki się nie zaloguje, więc w zasadzie zmusza do uwierzytelnienia hasła w pierwszej kolejności. Zobacz sekcję o zaszyfrowanym katalogu domowym pod następującym linkiem:

link

    
odpowiedział Willie Wheeler 11.07.2012, 08:48
źródło
5

Upewnię się, że twoje ustawienia w / etc / ssh / sshd_config są poprawne.

Aby wymusić użycie tylko PKI i odrzucić hasła, znajdź wiersz

#PasswordAuthentication yes 

w twoim pliku, odkomentuj go i ustaw na

PasswordAuthenticate no

Przeczytałbym również bilans ustawień, aby upewnić się, że mają sens. W szczególności spróbuj się upewnić, że używasz kluczy RSA, ponieważ wiadomo, że złamano zabezpieczenia DSA.

    
odpowiedział cmdematos 19.10.2011, 22:00
źródło
3

Jeśli zaznaczysz uprawnienia do katalogów i pojawi się "." zaraz po nich, możesz mieć włączony selinux, który będzie bałagan z wymianą kluczy, i domyślną ręczną identyfikacją haseł.

Możesz wyłączyć SELinux, aby rozwiązać problem, postępując zgodnie z instrukcjami tutaj: link , lub po prostu edytuj plik / etc / selinux / config i zmień go z" enforcing "na" disabled ".

Mam nadzieję, że to pomoże.

    
odpowiedział tweekd 30.07.2012, 00:28
źródło
2

Rozwiązałem ten problem, nie komentując "PasswordAuthentication yes" w / etc / ssh / sshd_config.

    
odpowiedział Ben Ernest 10.12.2013, 07:08
źródło
1

Z powodu potrzeby rozwiązywania problemów z komunikacją między dwoma różnymi komputerami miałem dwa prywatne klucze w ~/.ssh po stronie klienta.

Zamiast konfigurować każdy serwer z odpowiednim kluczem prywatnym w ~/.ssh/identity , tak jak powinienem, miałem drugi klucz (w tym przypadku nieprawidłowy) skonfigurowany dla wszystkich hostów:

Host *
IdentityFile ~/.ssh/identity_b

Poprawienie ~/.ssh/identity rozwiązało problem:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b
    
odpowiedział Uli Klumpp 24.04.2014, 03:33
źródło
1

Jedną z możliwych przyczyn problemu jest to, że masz klucze DSA, ale teraz SSH (podobno) domyślnie wymaga kluczy RSA. Mam problem z aktualizacją do 16.04. Możesz zobaczyć więcej tutaj , ale krótka odpowiedź to: ~/.ssh/config :

PubkeyAcceptedKeyTypes ssh-dss
    
odpowiedział DeegC 25.05.2016, 18:34
źródło
0

Miałem ten sam problem, ale zmiana uprawnień z chmod nie pomogła, ponieważ okazało się, że nie mam prawa własności do pliku ~/.ssh/authorized_keys . Możesz zmienić własność katalogu .ssh na:

sudo chown -R "$USER" ~/.ssh
    
odpowiedział Nick 23.09.2017, 08:30
źródło
-1

Jakoś to działało dla mnie:

root @ kaiser: ~ # vim / etc / ssh / sshd_config

Zmień ten wiersz z tak na nie  28 StrictModes no

Spróbuj ponownie

sysadmin @ suselinux1: ~ > con sysadmin kaiser Witamy w Ubuntu 12.04.1 LTS (GNU / Linux 3.2.0-25-generic i686)

Ostatnie logowanie: Fri 9 listopada 15:40:11 2012 od 10.1.3.25 sysadmin @ kaiser: ~ $ date vie nov 9 17:53:11 CST 2012 sysadmin @ kaiser: ~ $

    
odpowiedział theunbekanntshadow 10.11.2012, 01:06
źródło

Przeczytaj inne pytania na temat tagów