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

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: "my@email.address.com"
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEAr3Qo6T5XU06ZigGOd3eKvfBhFLhg5kWv8lz6
qJ2G9XCbexlPQGanPhh+vcPkhor6+7OmB+WSdHeNO652kTofnauTKcTCbHjsT7cJ
GNrO8WVURRh4fabknUHPmauerWQZ6TgRPGaz0aucU+2C+DUo2SKVFDir1vb+4u83
AV1pKxs=my@email.address.com
---- END SSH2 PUBLIC KEY ----

Skopiowałem część z „ssh-rsa AAA” do „my@email.address.com” 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]

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!

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

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

Musiałem zmienić uprawnienia do katalogu domowego

chmod 700 ~

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

~/.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.

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.

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.

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

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ć

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

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)

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

chmod 644 ~/.ssh/authorized_keys

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

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