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

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.

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

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)

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

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

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;

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.

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

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

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

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)

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 [email protected] -i /path/to/.pem file 

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

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.

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

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

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.

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