Odmowa zezwolenia SSH (publickey)


110

Próbuję połączyć się z Linode (z systemem Ubuntu 12.04 LTS) z mojego komputera lokalnego (również z systemem Ubuntu 12.04 LTS)

Utworzyłem klucz prywatny i publiczny na moim komputerze lokalnym i skopiowałem mój klucz publiczny do pliku autoryzowanych kluczy Linode. Jednak za każdym razem, gdy próbuję ssh na Linode, pojawia się komunikat o błędzie Permission denied (publickey).

Nie ma problemu z konfiguracją ssh na moim Linode, ponieważ mogę ssh do niego z mojego komputera z systemem Windows przy użyciu uwierzytelniania klucza.

W moim .sshkatalogu na moim lokalnym komputerze Ubuntu mam swoje id_rsai id_rsa.pubpliki. Czy muszę utworzyć plik autoryzowanych_kluczy na moim komputerze lokalnym?

EDYCJA: Oto, co dostaję, gdy uruchamiam ssh -vvv -i id_rsa [youruser]@[yourLinode]:

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

4
1) Co logi na serwerze SSH mówią o czasie, w którym błąd występuje na kliencie? ( /var/log/auth.log) 2) Jak przeniosłeś klucz publiczny na serwer? Zawsze używaj, ssh-copy-idaby mieć pewność co do uprawnień. Twój katalog domowy, .sshkatalog i authorized_keysplik mają surowe wymagania dotyczące uprawnień. (patrz strona man sshd(8) na ~/.ssh/authorized_keys). 3) Czy wygenerowałeś nową parę kluczy w Ubuntu? W przypadku ponownego użycia klucza z systemu Windows - najpierw musisz go przekonwertować na format OpenSSH.
gertvdijk

1
Polecenie powinno być ssh -vvv -i .ssh/id_rsa ....(zwróć uwagę na ścieżkę do id_rsa!) - zamień - stary dziennik pokazuje tylko, że „my” nie mieliśmy klucza pubKey do wysłania.
guntbert

@guntbert Brakowało mi pliku .ssh, ponieważ byłem już w katalogu .ssh. Próbowałem też z .ssh / id_rsa, ale uzyskałem ten sam wynik
Pattle

Rozumiem, więc źle odczytałem - odpowiedz na pytania z @gertvdijk.
guntbert

Czy ktoś może komentować na stackoverflow.com/questions/51254328/unable-to-ssh-to-bitbucket Mam podobny problem.
Mrinmay Kalita,

Odpowiedzi:


90

PubKeyAuthentication

Skonfiguruj swojego klienta

  1. Wygeneruj swój klucz
    • ssh-keygen
  2. Ssh skonfiguruj, aby używał klucza
    • vim ~/.ssh/config
  3. Skopiuj swój klucz na serwer
    • ssh-copy-id -i /path/to/key.pub SERVERNAME

Plik konfiguracyjny z kroku 2 powinien mieć coś podobnego do następującego:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Możesz dodać, IdentitiesOnly yesaby upewnić się, że sshużywa IdentityFileplików kluczy i nie ma ich podczas uwierzytelniania, co może powodować problemy i nie jest dobrą praktyką.

Rozwiązywanie problemów

  1. użyj opcji „-vvv”
  2. Upewnij się, że serwer ma klucz PUBLICZNY (.pub).
  3. Upewnij się, że Twój IdentiyFile wskazuje na klucz PRYWATNY.
  4. Upewnij się, że twój katalog .ssh ma 700, a twoje pliki mają 700 uprawnień (rwx ------).
  5. tail -f /var/log/auth.log (na serwerze) i monitoruj błędy podczas próby logowania
  6. Jeśli masz wiele plików kluczy, spróbuj IdentitiesOnly yesograniczyć uwierzytelnianie, aby użyć jednego określonego klucza.

1
Do twojej wiadomości, stworzyłem mały skrypt na github.com/centic9/generate-and-send-ssh-key, który uruchamia niezbędne kroki za jednym razem i dodatkowo zapewnia wszystkie uprawnienia do plików / katalogów, które zawsze powodowały bóle głowy ...
centic

1
Aby rozwinąć krok 2: IdentityFilewiersz w ~ / .ssh / config musi wskazywać na klucz PRYWATNY.
Danny Schoemann


3
Zastanawiam się, dlaczego chcesz ustawić pliki tak, aby miały uprawnienia do wykonywania w kroku 4?
Todd Walton

Jest to również bardzo ważne odpowiednie uprawnienia na użytkownika (użyj chown i chmod), w przeciwnym razie otrzymasz odmowę uwierzytelnienia, nawet jeśli serwer ma swój klucz publiczny.
joseluisq

61

Czasami problem pochodzi z uprawnień i własności. Na przykład, jeśli chcesz zalogować się jako root /root, .sshi authorized_keysmusi należeć do korzenia. W przeciwnym razie sshd nie będzie w stanie ich odczytać i dlatego nie będzie mógł stwierdzić, czy użytkownik jest uprawniony do zalogowania się.

W twoim katalogu domowym:

chown -R your_user:your_user .ssh

Jeśli chodzi o prawa, wybierz 700 dla .sshi 600 dlaauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

1
Ta odpowiedź pomogła mi. Skorzystałem z rad z tego postu i przeniosłem mój authorized_keysplik poza mój zaszyfrowany katalog domowy. Robiąc to, niechcący zmieniłem własność na root:root.
Jordan Grant,

Chciałbym móc dwukrotnie głosować, raz dla folderu i raz dla pliku. Bardzo ważne jest, aby uprawnienia były dokładne.
Pan Griever

Tak, to były uprawnienia przez cały czas.
a3y3

ten rozwiązał mój problem, dzięki za to.
sathiyarajan

14

Nie potrzebujesz authorized_keysna swoim kliencie.

Musisz powiedzieć klientowi ssh, aby faktycznie użył wygenerowanego klucza. Można to zrobić na kilka sposobów. Tylko do testowania typu ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. Będziesz musiał podać hasło za każdym razem, gdy chcesz połączyć się z serwerem.

Jeśli to zadziałało, możesz dodać klucz do ssh-agentz ssh-add .ssh/id_rsa(w tym celu musisz podać hasło tylko raz i powinno ono działać, dopóki nie wylogujesz się / nie uruchomisz ponownie)


Dzięki za pomoc, zredagowałem swoją odpowiedź, aby pokazać, co się stanie, gdy napiszę to, co zasugerowałeś.
Pattle

2
aby przenieść klucz, na kliencie, użyj ssh-copy-id
Panther

@ bodhi.zazen Dzięki, ale już przesłałem klucz, to nie są problemy
Pattle

4
„Musisz powiedzieć klientowi ssh, aby faktycznie użył wygenerowanego klucza”. Nie, domyślnie będzie szukał klucza w domyślnej ścieżce, np ~/.ssh/id_rsa. Ponadto użycie kluczowego agenta jest całkowicie opcjonalne i nie ma związku z tym problemem, o ile widzę.
gertvdijk

@gertvdijk, przyjmujesz tutaj założenia, które nie są jeszcze poparte faktami - nie wiemy, co się stało w systemie.
guntbert

10

Sprawdź także wartość PasswordAuthenticationw /etc/ssh/sshd_configi jeśli to nozmienisz na yes. Po tym nie zapomnij zrestartować usługi ssh.


4
OP nie próbuje użyć uwierzytelnienia za pomocą hasła. Mają pewien sens i używają klucza publicznego / prywatnego.
ctrl-alt-delor

9

Problem, który miałem, polegał na tym, że używałem niewłaściwych kluczy na kliencie. Zmieniłem nazwy id_rsa i id_rsa.pub na coś innego. Możesz albo zmienić ich nazwy z powrotem na domyślne, albo po wydaniu polecenia ssh użyj go w ten sposób

ssh -i ~/.ssh/private_key username@host

1
nie, użyj klucza publicznego
St3an

@ St3an umieściłeś klucz publiczny na serwerze, ale kiedy łączysz się tak, jak Todd jest tutaj powyżej, używasz swojego klucza prywatnego
Nathan F.

@NathanFiscaletti nigdy nie wolno ujawniać klucza prywatnego, dlatego jest prywatny. Klucz prywatny jest używany przez lokalnego agenta ssh, aby sprawdzić, czy naprawdę dajesz klucz publiczny, który odpowiada Twojemu kluczowi prywatnemu. Agenci SSH między komputerami mogą wtedy zagwarantować, że użytkownicy są tym, kim udają :-)
St3an

1
Dokładnie. Dlatego podczas łączenia przekazujesz swój klucz prywatny klientowi ssh. Serwer przechowuje twój klucz publiczny. Polecenie w powyższym poście dokładnie określa sposób użycia kluczy prywatnych.
Nathan F.

7

Upewnij się także, że katalog domowy użytkownika (na serwerze) faktycznie należy do użytkownika ssh'ing w (w moim przypadku ustawiono root: root).

Powinien był być:

sudo chown username:username /home/username;

Jestem w stanie ssh z kluczami publicznymi / prywatnymi z użytkownikiem na moim lokalnym systemie Linux (np. Abc), innym niż użytkownik na zdalnym serwerze (np. Def@123.456.789). Musiałem tylko upewnić się, że lokalny użytkownik jest właścicielem lokalnych plików .ssh (np. Abc: abc, a nie root: abc) `
Michael

To zadziałało w moim przypadku
Zerquix18,

3

Ostatnio natrafiłem na ten problem z moim serwerem internetowym.

Zazwyczaj przechowuję listę autoryzowanych kluczy na wszystkich moich serwerach w ~/.ssh/authorized_keys2. Z mojego doświadczenia wynika, że sshdbędzie szukać ~/.ssh/authorized_keyslub ~/.ssh/authorized_keys2domyślnie.

W przypadku mojego serwera /etc/ssh/sshd_configmiał on tę linię

AuthorizedKeysFile    %h/.ssh/authorized_keys

zamiast

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Zastosowałem to drugie, zrestartowałem demona ssh i rozwiązałem problem z logowaniem się za pomocą ssh przy użyciu mojego klucza pubkey.


Wielkie dzięki, pomogło mi to zorientować się, że ten wiersz został całkowicie skomentowany poza konfiguracją!
Christian.D.

2

Inną możliwą przyczyną może być AllowedUserskonfiguracja w /etc/ssh/sshd_conf. UWAGA: lista jest rozdzielana spacjami (nie przecinkami), ponieważ nauczyłem się na własnej skórze.

AllowUsers user1 user2 user3

1

Jeśli wszystko inne się nie powiedzie, sprawdź, czy twój login należy do Dozwolonej Grupy ssh. Oznacza to, że użytkownicy są członkami grupy wyświetlanej w następującym wierszu /etc/ssh/sshd_configna serwerze:

AllowGroups ssh #Here only users of 'ssh' group can login

1

W moim przypadku klientem jest Ubuntu 14.04lts, serwer został wygrany w 2012 roku serwer z uruchomionym cygwin. Używałem „ssh administrator @ xxxx”, gdy katalogiem serwera 2012 w cygwin był / home / Administrator. Dlatego rozróżniano wielkość liter, kiedy próbowałem „ssh Administrator @ xxxx” (zwróć uwagę na wielką literę A na Administratorze), to działało dobrze.

Komunikat o błędzie „Nie znaleziono użytkownika” doprowadziłby mnie do rozwiązania o wiele szybciej niż „Odmowa dostępu (publickey, klawiatura interaktywna)”.


Ktoś powinien zalogować problem z sugerowanym przez projekt ssh. Wystąpił podobny problem.
Ben Creasy

1

Miałem ten sam problem podczas kopiowania klucza publicznego zwykłego użytkownika (np. Johndoe) z systemu cPanel Centos na serwer Ubuntu na AWS. Jak sugeruje gertvdijk powyżej, sprawdziłem /var/log/auth.logi na pewno to powiedział Authentication refused: bad ownership or modes for directory /home/johndoe. Okazuje się, że źle wprowadziłem 777'ów, /home/johndoegdy próbowałem ustawić /home/johndoe/public_htmljako domyślny katalog główny katalogu wirtualnego hosta dla apache2 (nie jest to również potrzebne do tego zadania).

Zobacz także odpowiedzi tutaj i tutaj

Serwer musi mieć tylko klucz publiczny, .ssh/authorized_keysa klient (komputer, na którym pracujesz) musi mieć klucz prywatny (.pem lub jeśli używasz SFTP z Filezilla, .ppk)


1

W przypadku użytkowników Putty, takich jak ja, którzy przyszli do tego wątku, możesz również otrzymać ten błąd, jeśli zapomniałeś dodać użytkownika użytkownik @ Ip!

Inni są uprawnieni do pliku klucza chmod do 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file 

1

To działało dla mnie, poprawka nie jest moja, ale wolę ją tutaj zapisać na wypadek, gdyby ktoś miał ten sam problem.

Oryginalny autor opublikował go tutaj: digital-ocean-public-access-key-denied

sudo nano /etc/ssh/sshd_config

Wymień to

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Z tym

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Zapisz plik i uruchom ponownie ssh

reload ssh

ssh powinien teraz działać, prosząc o hasło


1

Miałem ten sam problem, co opisany w pytaniu. Wynik działania ssh -vvv -i id_rsa [youruser]@[yourLinode]na komputerze klienckim był podobny do opisanego w pytaniu. Sprawdziłem wszystkie uprawnienia do plików i katalogów zgodnie z zaleceniami w innych odpowiedziach i były one poprawne.

Okazało się, że podczas kopiowania wygenerowanego pliku id_rsa.pubna serwer, jako plik ~username/.ssh/authorized_keys, przypadkowo pominąłem to słowo ssh-rsaod samego początku. Dodanie go rozwiązało problem.


1

Działa również na Ubuntu 16.04.

Problem znajduje się w sshd_configpliku

Oto rozwiązanie ULTIMATE:

Zaloguj się jako root do serwera Ubuntu

vi /etc/ssh/sshd_config

Teraz zejdź na sam dół i zmień wartość z „nie” na „tak”.

To powinno wyglądać tak:

Zmień na no, aby wyłączyć tunelowane hasła w postaci czystego tekstu

PasswordAuthentication yes
service sshd reload

zadziałać.

Teraz możesz po prostu nacisnąć klawisz, używając następującego polecenia z komputera LOCAL (aka laptop itp.)

Więc otwórz nowe okno terminala i NIE loguj się do serwera, po prostu wpisz następujące polecenie:

ssh-copy-id jan @ serverIPAddress

(Zamień John na swoją nazwę użytkownika).

powinieneś iść iść


1

Niektórzy ludzie zastanawiają się, że skonfigurowali dostęp ssh jako kluczowy tylko dla konta root, a następnie utworzyli nowego użytkownika i nie zdawali sobie sprawy, że muszą

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Następnie spróbuj ponownie. Zastąp [użytkownik] nowym kontem użytkownika.

Jest to powszechne podczas konfigurowania nowego serwera w DigitalOcean, gdy używasz klawiszy ssh podczas instalacji.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04


0

W moim przypadku problem został spowodowany przez skopiowanie .sshkatalogu ze starszego komputera. Okazuje się, że moja starsza konfiguracja SSH używała kluczy DSA, które od tego czasu były przestarzałe . Przejście na nową parę kluczy, tym razem opartych na RSA, rozwiązało problem.


0

Poniższa metoda może działać, jeśli można uzyskać dostęp do komputera A i komputera B niezależnie (np. Z komputera C).

Jeśli ssh-copy-id nie działa, uwierzytelnianie hasła może być wyłączone. Oto obejście .

Posiadanie klucza publicznego maszyny A w autoryzowanych kluczach maszyny B (tj. ~ / .Ssh / uprawnione_klucze) pozwoli ci na ssh z maszynyA. Dotyczy to również scp.

Po wygenerowaniu par kluczy za pomocą: ssh-keygen

Na komputerze A wykonajcat ~/.ssh/id_rsa.pub

Przykładowe dane wyjściowe:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Skopiuj wydrukowany klucz ( ⌘ Command+ Club CRTL+ C), a następnie dodać go do pliku ~ / .ssh / authorized_keys na machineB .

Na przykład wykonaj następujące czynności na komputerze B :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys

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.