Próba wykonania uwierzytelnienia ssh przy użyciu plików kluczy: serwer odrzucił nasz klucz

53

Próbuję skonfigurować uwierzytelnianie ssh za pomocą plików kluczy zamiast nazwy użytkownika / hasła. Klientem jest Windows z systemem PuTTY, a serwerem jest serwer Ubuntu 12.04 LTS.

Pobrałem puttygen.exe i wygenerowałem parę kluczy. W /etc/ssh/sshd_configmam ten wiersz:

AuthorizedKeysFile %h/.ssh/authorized_keys

a na pliku klucza publicznego mojego klienta jest napisane:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "[email protected]"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
[email protected]
---- END SSH2 PUBLIC KEY ----

Skopiowałem część z „ssh-rsa AAA” do „[email protected]” i umieściłem ją w pliku ~/.ssh/authorized_keysna moim serwerze (we własnym folderze domowym). W PuTTY w obszarze Połączenie> SSH> Auth podałem ścieżkę do klucza prywatnego wygenerowanego na moim kliencie i zapisałem ustawienia sesji.

Zrestartowałem serwer ssh za pomocą

sudo service ssh restart

Teraz, jeśli załaduję profil w PuTTY (sprawdziłem, że klucz prywatny jest nadal w Połączeniu> SSH> Auth i czy ścieżka jest poprawna) i uruchomię profil, wyświetli się komunikat

Server refused our key

Próbowałem umieścić klucz publiczny w pliku w katalogu, ./ssh/authorized_keys/ ale to nie pomogło, więc użyłem go ./ssh/authorized_keysjako pliku , wklejając w nim klucz. Próbowałem także wygenerować parę kluczy prywatny / publiczny na serwerze, wkładając klucz publiczny ./ssh/authorized_filesi ładując klucz prywatny w PuTTY na moim kliencie. Ponowne uruchomienie serwera też nie pomogło.

Odkryłem, że błąd można rozwiązać, umieszczając klucz w miejscu poza folderem domowym użytkownika, ale jest to przydatne tylko wtedy, gdy folder domowy jest zaszyfrowany, a ten nie jest.

Próbowałem także wygenerować 4096-bitowy klucz, myśląc, że 1024 może być za krótkie.

Jak mogę to uruchomić? Dzięki!

EDYTOWAĆ:

Ok, /var/log/auth.logpowiedział:

sshd: Authentication refused: bad ownership or modes for directory /home/vorkbaard/.ssh

Google mówi mi, że ~/.ssh/powinno to być 700, a ~/.ssh/authorized_keyspowinno być 600, więc to zrobiłem. Teraz /var/log/auth.logmówi:

sshd: error: key_read: uudecode AAAAB3N [etc etc etc until about 3/4 of my public key]
Widelec
źródło

Odpowiedzi:

95

Ok, zostało to naprawione, jednak nie widzę, jak różni się to od tego, co już próbowałem.

Co ja zrobiłem:

  • wygeneruj parę kluczy za pomocą puttygen.exe (długość: 1024 bity)
  • załaduj klucz prywatny do profilu PuTTY
  • wprowadź klucz publiczny ~/.ssh/authorized_keys w jednym wierszu (musi zaczynać się od ssh-rsa)
  • chmod 700 ~/.ssh
  • chmod 600 ~/.ssh/authorized_keys
  • chown $USER:$USER ~/.ssh -R
  • zmień, /etc/ssh/sshd_configaby zawierałAuthorizedKeysFile %h/.ssh/authorized_keys
  • sudo service ssh restart

Aby rozwiązać problem, wykonaj # tail -f /var/log/auth.log.

Dzięki za pomoc!

Widelec
źródło
1
Hmm, więc co się stało z tym sshd: error: key_read: uudecode AAAAB3Nbłędem auth.log?
Alaa Ali,
Nie mam pojęcia, Alaa. Być może popełniłem błąd wklejając poprzedni ciąg klucza. Auth.log nie otrzymuje już żadnych wpisów, a uwierzytelnianie oparte na kluczach działa bezbłędnie. Moim głównym problemem było to, że nie był pewien, o co trzeba zrobić, dzięki czemu , jak to o wiele trudniejsze. Więc nie wiem dlaczego, ale działa. Jeszcze raz dziękuję za pomoc :)
Forkbeard
Niesamowite!!! Drapam się po głowie od 2 dni. Te odpowiedzi ratują dzień !!
naka
Krok 3 był dla mnie sztuczką. Nie umieściłem klucza publicznego w authorized_keyspliku, właśnie wkleiłem mój mykey.pubplik do ~/.sshfolderu i pomyślałem, że go podniesie. Zamiast tego ostatecznie potrzebowałem uruchomić to lub edytować i wkleić poniżej innych kluczy, które mogą tam być. cat mykey.pub >> authorized_keys. Wydaje się to teraz proste, ale wyciągniętą lekcją jest to, że wszystkie klucze publiczne muszą znajdować się authorized_keysnie tylko w ~/.ssh/katalogu. Ktoś proszę doradzić, jeśli nie jest to prawidłowe stwierdzenie.
timbrown
jeśli kroki nie pomogą, sprawdź również: 1. skopiowałeś zapisany klucz publiczny PuTTY do kluczy autoryzowanych, a nie OpenSSH 2. jeśli skopiowałeś używając kopiuj / wklej z PuTTYgen (co powinieneś zrobić), być może podzieliłeś klucz publiczny w wielu wierszach; powinna to być pojedyncza linia; upewnij się, że nie dodałeś wiodących ani końcowych spacji podczas kopiowania dzięki r_hartman centos.org/forums/viewtopic.php?t=990
mvladk
23

Właśnie spotkałem ten problem. Pomimo prawidłowego ustawienia konfiguracji, jak już wspomniano w tym wątku (uprawnienia do kluczy autoryzowanych itp.), Okazuje się, że miałem klucz publiczny w niewłaściwym formacie. Miał postać:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "imported-openssh-key"
AAAAB3NzaC1yc2EAAAADAQABAAABAQDUoj0N3vuLpeviGvZTasGQ...
... lPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT
---- END SSH2 PUBLIC KEY ----

Co nie działało. Ale sprawiło, że działało, mając to w postaci:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDU.....j0N3vuLpeviGvZTasGQa1rcJiPXQMW7v3uurb+n94B9MQaaWR0odsg5DJQL92TNenOda5BO1nd08y6+sdLQmHXExTz6X8FzgoVsAkEl3RscxcxHUksiKA9JfTo38vQvG/bPxIHMCuSumCQVA1laf3rO/uOrkcB7iMWhaoi1/z6AbFtPzeh7xjGfInMWwtBI0CsHSRF73VWIxT26w0P+KjafCjSn/7vDO1bT8QHujSQelU/GqaVEvbbvPl1a7POVjKgHLNekolwRKfNeVEewcnmZaoqfHgOKlPmTrOfVTxI9wjax2JvKcyE0fiNMzXO7qiHJsQM9G9ZB4Lkf71kT UserName@HOSTNAME
kuraara
źródło
14
Możesz użyć ssh-keygen -i -f filenameofwindowsformpub.keydo przekształcenia klucza publicznego w format zrozumiały dla twojego serwera OpenSSH.
Czarny
Tak, zadziałało dla mnie! Musi być w jednej linii. Nie mogę uwierzyć, że to tylko to!
adelriosantiago
1
Cześć kuraara. Uważam, że powyższa instrukcja @Black powinna zostać wyróżniona w odpowiedzi.
ekerner
Czy mogę dodać komentarz do formatu serwera OpenSSH? Dla człowieka trudno jest powiedzieć, jaki komputer reprezentuje ten klucz.
user1700890
Kiedy podążam za sugestią @Black, na końcu ciągu nie ma nazwy użytkownika @ HOSTNAME. Nie wiem, czy ta część ma znaczenie.
arnoldbird
9

Problem polega na tym, że Windows używa innej nowej linii niż Linux, więc podczas kopiowania klucza z Windows do Linuksa na końcu linii znajduje się \ n , którego nie widać na edytorze Linux.

Jeśli przejrzysz /var/log/auth.log i spróbujesz się zalogować, błąd wygląda następująco:

sshd: error: key_read: uudecode AAAAB3N [....] == \ n

Jeśli zmienisz swój klucz w systemie Windows, tak aby znajdował się w jednej linii bez nowej linii na końcu i skopiowałeś go następnie do Linuksa, powinien on działać (załatwił sprawę dla mnie).

Mischa
źródło
to był mój problem, ale nie widziałem niczego w auth.log, co sugerowałoby, że tak jest. frustrujące ...
Anthony
8

Musiałem zmienić uprawnienia do katalogu domowego

chmod 700 ~
Michał Zmuda
źródło
2
Działa to również dla mnie (w systemie AIX).
stevepastelan
Pracowałem również dla CentOS
Jaywalker,
Pracował dla mnie w Redhat! Grupowy dostęp do zapisu wydaje się być specyficznym problemem. Nadal działa dla mnie, jeśli pozostawię uprawnienia odczytu grupowego na miejscu: „chmod 740 ~”.
Paul
6

Musiałem zmienić uprawnienia do katalogu ~ / .ssh z 770 na 700 oraz uprawnienia do pliku ~ / .ssh / author_keys z 660 na 600.

Z jakiegoś powodu usunięcie uprawnień grupowych naprawiło ten problem.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
dopple
źródło
5

~/.ssh/authorized_keysPlik wymaga kluczy być w jednej linii. Jeśli dodałeś go do wielu linii, jak w powyższej wklejce, spróbuj połączyć linie.

Paweł
źródło
Dzięki, to ma sens i teraz rozumiem, dlaczego jest to plik, a nie katalog. Jednak to nie pomogło.
Forkbeard
3
dla każdego, kto może być tym zdezorientowany, chodzi mu o to, że każdy klucz musi znajdować się w jednym wierszu, ale różne klucze muszą znajdować się w różnych wierszach.
Anthony
2

Oto, co zadziałało dla mnie:

W puttygenpo wygenerowaniu kluczy, upewnij się, że kopiowanie i wklejanie informacji z górnym polu, aby przejść do pliku authorized_keys. Jeśli zapiszesz swój klucz publiczny na komputerze klienckim, a następnie go otworzysz, tekst różni się od tekstu u góry puttygenekranu. Ponownie upewnij się, że skopiowałeś i wkleiłeś tekst z GÓRY puttygenekranu (po utworzeniu kluczy) do pliku autoryzowanych_kluczy, w którym powinien się znajdować ~/.ssh.

zach
źródło
to naprawiło problem. nie rozumiem dlaczego, jeśli klikniesz przycisk Zapisz klucz publiczny, dlaczego nie zapisuje odpowiedniego formatu.
luky
1

Oprócz wszystkich powyższych odpowiedzi upewnij się, że puttygenpoprawnie skopiowałeś i wkleiłeś klucz !

Po dwukrotnym kliknięciu większości ciągu klucza, aby go wybrać, możesz nie otrzymać całego łańcucha, ponieważ pole tekstowe dzieli linie na niektóre znaki, na przykład +tak, że nie zaznaczasz tekstu po +znaku ( którego nie widać, ponieważ pole tekstowe jest zbyt małe). Pamiętaj, aby wybrać cały ciąg ręcznie, od ssh-rsasamego końca pola tekstowego.

Mark Lakata
źródło
1

Czasami może to być problem związany z posiadaniem klucza publicznego w jednej linii, takie podejście wydaje się go rozwiązać

echo 'the content of the public key' > /root/.ssh/authorized_keys
dav
źródło
1

dla mnie problem polegał na tym, że utworzyłem ~/.ssh/authorized_keysroot, więc root to własność root. Musiałem chown sshuser:sshuser ~/.ssh/authorized_keyswtedy zacząć działać

PeanutPower
źródło
1

Ja również spotkałem się z tym błędem i rozwiązałem go, zmieniając uprawnienia pliku autoryzowanych_kluczy na 600.

chmod 600 ~/.ssh/authorized_keys
Kaleem
źródło
1

Częstym błędem jest to, że ludzie używają edytora tekstu (takiego jak Vim) i wklejają skopiowany tekst przed aktywowaniem „wstawiania” (naciśnij + i w Vimie przed wklejeniem)

hakabe
źródło
0

W rzeczywistości zmieniłem authorized_keysuprawnienia 644, a następnie problem rozwiązany.

chmod 644 ~/.ssh/authorized_keys
Peter Liang
źródło
0

do debugowania otwartego ssh można użyć:

sudo `which sshd` -p 2020 -Dd

uruchamia sshd na innym porcie 2020. uruchamia sshd jako bieżący program, więc wyjście przechodzi na ekran. jeśli zamknięty jest zamknięty.

następnie spróbuj się połączyć.

wyjaśnienie:

  • `which sshd` - lokalizuje adres sshd, spróbuj wykonać, który sshd zobaczy, co drukuje. gdy używasz cudzysłowu, wykonuje i zwraca wynik na miejscu.
  • -p 2020 - określa port
  • -D - zaloguj się do pliku
  • -d - zaloguj się do ekranu

https://www.attachmate.com/documentation/rsit-unix-802/rsit-unix-guide/data/sshd_options_ap.htm

Shimon Doodkin
źródło
Czy mógłbyś rozwinąć tę odpowiedź? Co pociągają za sobą argumenty? Co robi polecenie (dla kogoś, kto nie ma doświadczenia)?
Zzzach ...
-1

Tworzyłem pliki .ssh i autoryzowane klucze podczas logowania jako root, co dawało złe uprawnienia. Umieścił również wszystkie pliki w katalogu głównym.

Zmiana własności tych plików na pożądanego użytkownika nie będzie dobrą praktyką, więc powtórzyłem swoje kroki i upewniłem się, że jestem zalogowany jako użytkownik, z którego chciałem korzystać z SSH, i ponownie utworzyłem .ssh i uprawnione klucze.

Wskazówki dotyczące połączenia Win7 z serwerem Xubuntu 15.04: Jak utworzyć klucze SSH w / Putty, aby połączyć się z VPS

Leo Fisher
źródło