Putty: Getting Server odrzucił nasz błąd klucza

Utworzyłem parę kluczy za pomocą puttygen.exe(klient to Windows 8). Na serwerze (Ubuntu 12.04.3 LTS) umieściłem swój klucz publiczny ~/.ssh/authorized_keys. Klucz publiczny jest następujący:

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAopfM6RHOgnuc4Aftn3t4k5UIAT3StCAbn/vg/IMbphbXadshC+79sIlRq3P4zGzMjFTP4hKnzu6ehLV5lmj/qorq3SKT+bPO5Qrac3VbIlrGvuBFDDjP82I2Hwg3HzlsFTstqk++KToapaTYZ7jENEYyPl2wnzITJnt//+4U1o6juoXTKgdNE02hHnRZyHOV/bnkZyJJCEwJv5U0eXSThQnhmXtUxGT8U0HQNFiXfqIIVllhWiCnyrhhIaKz/CIJNAd2VmzyJzQtJtTQX8aWSNVrZju6Sv2/RncTNvsACdNgjjh/FH8PQXaep00jlJ3MOdsC8vz6VSPFbh6iKy1oLQ== rsa-key-20131231

Więc jest poprawna (jedna linia, bez komentarzy, zaczyna się od ssh-rsa itp.)

.ssh dir poziom uprawnień to 700, uprawnienia do pliku allowed_keys to 600. Zarówno katalog, jak i plik należą do rzeczywistego użytkownika, którego próbuję się zalogować.

Kiedy próbuję się połączyć, otrzymuję 'server refused our key'i serwer pyta o hasło. To wszystko. Nic nie jest rejestrowane /var/log/auth.logpodczas próby zalogowania się za pomocą klucza.

Szukałem wszędzie i wszystkie artykuły i wskazówki wspominają o ustawieniu chmod 600 i 700 dla pliku / katalogu i poprawnym formatowaniu klucza. Zrobiłem to wszystko, wciąż otrzymując błąd „odmówił nam klucza” i nie mam pomysłów.

OK, w moim kluczu była mała literówka. Najwyraźniej podczas wklejania do pliku pierwsza litera została odcięta i zaczynała się od sh-rsa zamiast ssh-rsa.

nrathathaus - twoja odpowiedź była bardzo pomocna, wielkie dzięki, ta odpowiedź jest ci przypisana :) Tak jak powiedziałeś i ustawiłem to w sshd_conf:

LogLevel DEBUG3

Patrząc na logi zdałem sobie sprawę, że sshd poprawnie odczytuje klucz, ale odrzuca go z powodu nieprawidłowego identyfikatora.

Dodanie kilku myśli jako innych odpowiedzi pomogło, ale nie były one dokładnie dopasowane.

Przede wszystkim, jak wspomniano w zaakceptowanej odpowiedzi, edytuj

/etc/ssh/sshd_config

i ustaw poziom dziennika:

LogLevel DEBUG3

Następnie spróbuj się uwierzytelnić, a gdy się nie powiedzie, poszukaj pliku dziennika:

/var/log/secure

Będzie zawierał błędy, których szukasz.

W moim przypadku musiałem również zmienić uprawnienia / home / user z 0755 na 0700.

W moim przypadku jest to problem z uprawnieniami.

Zmieniłem poziom dziennika na DEBUG3i /var/log/securewidzę tę linię:

Authentication refused: bad ownership or modes for directory

Wyszukałem w Google i znalazłem ten post:

https://www.daveperrett.com/articles/2010/09/14/ssh-authentication-refused/

chmod g-w /home/your_user
chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

Zasadniczo nakazuje mi:

• pozbyć się wuprawnień grupowych swojego użytkownika home dir
• zmień uprawnienia 700na .sshreż
• zmienić uprawnienia do 600tego authorized_keyspliku.

I to działa.

Inną rzeczą jest to, że nawet jeśli włączyłem logowanie jako root, nie mogę zabrać się rootdo pracy. Lepiej użyj innego użytkownika.

Uruchamiając Windows 8.1 napotkałem server refused our keyproblem.

Postępując zgodnie z instrukcją: https://winscp.net/eng/docs/guide_windows_openssh_server Nawiązanie połączenia przy użyciu logowania do systemu Windows usernamei password. Jednak po uwierzytelnieniu usernamew połączeniu z a private key, odpowiedź była server refused our key.

Uruchomienie go z kluczem publicznym sprowadzało się do uprawnień do pliku: C:\ProgramData\ssh\administrators_authorized_keys

To jest pomocna strona: https://github.com/PowerShell/Win32-OpenSSH/wiki/Troubleshooting-Steps

Zatrzymaj dwie usługi OpenSSH, a następnie otwórz plik za command promptpomocą admin permissions. Następnie uruchomić: C:\OpenSSH-Win32>c:\OpenSSH-Win32\sshd.exe -ddd

Uwaga: podaj pełną ścieżkę do pliku exe, w przeciwnym razie sshdnarzeka. Tworzy to nasłuchiwanie połączeń jednorazowego użytku. -dddJest rozwlekły poziomie 3.

Po nawiązaniu połączenia skanowanie logów ujawniło:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Failed to open file:C:/ProgramData/ssh/administrators_authorized_keys error:2
debug1: Could not open authorized keys '__PROGRAMDATA__/ssh/administrators_authorized_keys':
        No such file or directory

Musiałem stworzyć plik: C:\ProgramData\ssh\administrators_authorized_keys I skopiować do niego public keytekst, np .: ssh-rsa AAAA................MmpfXUCj rsa-key-20190505 A potem zapisać plik. Uratowałem jak plik UTF-8z BOM. Nie testowałem ANSI.

Następnie ponownie uruchomiłem jednorazową linię poleceń, w dziennikach pokazało się:

debug1: trying public key file __PROGRAMDATA__/ssh/administrators_authorized_keys
debug3: Bad permissions. Try removing permissions for user: S-1-5-11 on file C:/ProgramData/ssh/administrators_authorized_keys.
        Authentication refused.

S-1-5-11to nazwa nadana System.

Aby naprawić Bad permissions, kliknij prawym przyciskiem myszy administrators_authorized_keysplik Security Tab, przejdź do, kliknij Advancedprzycisk i usuń odziedziczone uprawnienia. Następnie usuń wszystko Group or user names:oprócz nazwy użytkownika logowania do systemu Windows, np .: YourMachineName\username Uprawnienia do tego usernamepowinny być Read Allow, Write Denywszystko inne jest odznaczone. Właścicielem pliku również powinien byćYourMachineName\username

To rozwiązało problem.

Inne przydatne linki:

Pobierz OpenSSH-Win32.zip z: https://github.com/PowerShell/Win32-OpenSSH/releases

Przykład w C #, jak używać WinSCPnet.dll do nawiązywania połączenia z serwerem OpenSSH: https://winscp.net/eng/docs/library#csharp

Oto fragment kodu umożliwiający nawiązanie połączenia za pomocą WinSCPnet.dll:

static void WinSCPTest() {
    SessionOptions ops = new SessionOptions {
        Protocol = Protocol.Sftp, 
        PortNumber = 22,
        HostName = "192.168.1.188", 
        UserName = "user123",
        //Password = "Password1",
        SshHostKeyFingerprint = @"ssh-rsa 2048 qu0f........................ddowUUXA="
    };

    ops.SshPrivateKeyPath = @"C:\temp\rsa-key-20190505.ppk";

    using (Session session = new Session()) {
        session.Open(ops);
        MessageBox.Show("success");
    }
}

Zastąp SshHostKeyFingerprinti SshPrivateKeyPathwłasnymi wartościami.

Edycja: dodano zrzut ekranu uprawnień do plików administrators_authorized_keys:

Gdy OpenSSH SSH Serverdziała jako usługa, Systempowinno mieć tylko pozwolenie. Jeśli jednak uruchamiasz sshd.exez wiersza poleceń, bieżący użytkownik powinien być jedynym na liście (zezwolenie na odczyt, odmowa zapisu).

Dodaję tę odpowiedź, aby pomóc każdemu, tak jak ja, który spędził godziny bezskutecznie przeszukując internet.

TWÓJ DOMOWY FOLDER MOŻE BYĆ ZASZYFROWANY.

Lub też dowolny folder, w którym zagnieżdżony jest twój plik "authorised_keys". Człowieku, to zaoszczędziłoby mi dużo czasu. Aby to sprawdzić, idź grać

ls -A

w katalogu, którego stan szyfrowania chcesz określić. Jeśli folder zawiera folder o nazwie „.encryptfs”, odpowiedź brzmi: tak, ten folder jest zaszyfrowany. Utrudni to dostęp do pliku „authoris_keys” zawierającego publiczny klucz ssh potrzebny do weryfikacji.

Aby to naprawić, umieść plik „authorised_key” w drzewie katalogów, które nie zawiera szyfrowania.

Prostym rozwiązaniem, które znalazłem, było przeniesienie authorized_keyspliku z ukrytego katalogu .ssh i umieszczenie go w systemowym katalogu ssh:

/etc/ssh/keys/authorized_keys

Jak tylko to zrobiłem, działało bez problemów.

mając ten sam problem w systemie Windows Server 2008 R2 i zbadałem wiele do rozwiązania, w końcu zrobiłem to, wykonując następujące czynności:

otwórz C: \ Program Files (x86) \ OpenSSH \ etc \ sshd_config za pomocą textpada lub dowolnego innego edytora tekstu

usuń komentarz z poniższych linii, po usunięciu powinny wyglądać następująco:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

zapisz go i spróbuj teraz zalogować się przy użyciu klucza prywatnego. baw się dobrze.

Podziękowania dla nrathaus i /var/log/auth.logdochodzenia na poziomie debugowania są następujące.

Innym powodem jest to, że twój katalog domowy może mieć inne uprawnienia niż 755.

Napotkałem ten problem dzisiaj i moim problemem było to, że podczas kopiowania klucza publicznego z pliku dołączane są również znaki nowego wiersza. Możesz użyć ": set list" w vimie, aby zobaczyć wszystkie ukryte nowe linie i upewnić się, że usunąłeś wszystkie nowe linie z wyjątkiem ostatniej. Poza tym na początku brakowało mi klucza „ssh-rsa”. Upewnij się, że też to masz.

W przypadku osób otrzymujących ten błąd z systemu Windows Server otrzymałem ten sam błąd i był to problem z kontem użytkownika. W wielu organizacjach zasady grupowe dla administratorów mogą nie zezwalać na konfigurowanie serwera SSH i połączeń. W przypadku tego typu konfiguracji należy to zrobić z konta administratora lokalnego. Może warto to sprawdzić, jeśli potwierdzisz, że w kluczu publicznym nie ma żadnych literówek.

W moim przypadku musiałem wyłączyć SELinux na Centos6.6, aby działał :)

Edytuj / etc / selinux / config i ustaw poniższe, a następnie uruchom ponownie hosta.

selinux=disabled

BTW ... zapomniałem wspomnieć, że musiałem ustawić LogLevel = DEBUG3, aby zidentyfikować problem.

Miałem ten sam błąd na Solaris, ale znalazłem w /var/adm/splunk-auth.log następujące informacje:

sshd: [auth.debug] debug1: PAM conv function returns PAM_SUCCESS
sshd: [auth.notice] Excessive (3) login failures for weblogic: locking account.
sshd: [auth.debug] ldap pam_sm_authenticate(sshd-kbdint weblogic), flags = 1
sshd: [auth.info] Keyboard-interactive (PAM) userauth failed[9] while authenticating: Authentication failed

W / etc / shadow konto zostało zablokowane:

weblogic:*LK*UP:16447::::::3

Usunięto część „* LK *”:

weblogic:UP:16447::::::3

i mógłbym jak zwykle użyć ssh z autoryzowanymi_kluczami.

W moim przypadku było to spowodowane przez ( /etc/ssh/sshd_config):

PermitRootLogin no

Zmieniłem się na yes, zrestartowałem usługę i wróciłem normalnie.

Rozwiązałem ten problem, puttygen to oprogramowanie innej firmy, wygenerowany przez niego klucz ssh nie był używany bezpośrednio, więc musisz wprowadzić pewne zmiany. Na przykład wygląda to tak

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7
*******C4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ==
---- END SSH2 PUBLIC KEY ---- 

Pomijam niektóre alfabety w środku, zastępuję je *, jeśli nie, StackOverflow powiedział mi, że format kodu jest zły, nie pozwól mi pisać。

to jest mój klucz ssh wygenerowany przez puttygen, musisz zmienić na to

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAr4Ffd3LD1pa7KVSBDU+lq0M7vNvLp6TewkP7wfvKGWWR7wxA8GEXJsM01FQw5hYWbNF0CDI7nCMXDUEDOzO1xKtNoaidlLA0qGl67bHaF5t+0mE+dZBGqK7jG9L8/KU/b66/tuZnqFqBjLkT+lS8MDo1okJOScuLSilk9oT5ZiqxsD24sdEcUE62S8Qwu7roVEAWU3hHNpnMK+1szlPBCVpbjcQTdiv1MjsOHJXY2PWx6DAIBii+/N+IdGzoFdhq+Yo/RGWdr1Zw/LSwqKDq1SmrpToW9uWVdAxeC4eq1cdJACBPyjqUCoz00r+LqkGA6sIFGooeVuUXTOxbYULuNQ== yourname@hostname

W moim przypadku usunąłem niektóre komentarze, takie jak

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "rsa-key-20170502"
---- END SSH2 PUBLIC KEY ----

i dodaj ssh-rsana początku, dodaj yourname@hostnamena końcu. uwaga : nie usuwaj ==na końcu i musisz zmienić dla siebie "twoje imię" i "nazwę hosta", w moim przypadku uaskh@mycomputertwoja nazwa jest taka, że ​​chcesz zalogować się do swojego vps. kiedy wszystko to zrobi, możesz przesłać publicznie -klawisz do domu uaskh jest ~/.ssh/authorized_keyso cat public-key >> ~/.ssh/authorized_keysczym sudo chmod 700 ~/.ssh sudo chmod 600 ~/.ssh/authorized_keysto musisz zmodyfikować / etc / ssh / sshd_config, RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keysmój system operacyjny CentOS 7, jest to mój pierwszy raz anwser pytanie, postaram moje wysiłki do zrobienia, Dziękuję!

O mój Boże, spędziłem dni próbując to naprawić. Więc oto, co zadziałało dla mnie. Wróciłem do folderu głównego w ten sposób: cd / root / mkdir .ssh cd .ssh chmod 700 .ssh nano -w autoryzowany_klucze usługa ssh restart Więc użyłem roota do logowania przez Putty i zadziałało. więc spróbuj zrobić to samo z użytkownikiem, którego chcesz użyć w kitu.

Używam pliku PUTTYgen z psftp i napotkałem ten problem na moim Windows Server, kiedy musieliśmy utworzyć nowe klucze dla klienta. Aby połączenie działało, plik private_key_name .ppk i open_ssh.txt muszą znajdować się w tym samym katalogu.

W moim przypadku dom na nfs to 777, potrzeba 750. To rozwiązało problem.

Mam problem, w którym sshd tylko czyta authorized_keys2.

Skopiowanie lub zmiana nazwy pliku rozwiązało problem.

cd  ~/.ssh
sudo cat authorized_keys >> authorized_keys2

PS Używam Putty z Windows i użyłem PuTTyKeygen do generowania par kluczy.

Miałem podobny problem, próbując zalogować się przez Mobaxterm. Klucz prywatny został wygenerowany przez puttygen. Regeneracja klucza pomogła w moim przypadku.

Używając Cpanel możesz sprawdzić, czy klucz jest autoryzowany w

Dostęp SSH >> Klucze publiczne >> Zarządzaj >> Autoryzuj lub Cofnij autoryzację.

jeśli pojawi się ten błąd w /var/log/secure

błąd: key_read: key_from_blob AA
AAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG + rKz93l7em1BsUBzjHPMsswD

oznacza to, że twój klucz ma spację, jeśli wygenerowałeś klucz przez puttgen podczas przeglądania .ppkpliku, będzie wyglądał tak:

AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswD
al74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5
GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBC
gLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqz
xjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5L
VwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ==

a kiedy spróbujesz go wkleić, pojawi się błąd w odczycie klucza, więc spróbuj edytować klucz, zrób go w jednej linii i wypróbuj

to powinno wyglądać na coś

ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAQEAoo3PFwX04NFG+rKz93l7em1BsUBzjHPMsswDal74MLaJyhQD0pE23NS1izahbo1sJGnSJu2VJ//zxidSsba6xa6OvmeiKTwCz0E5GMefdGVdpdbTlv99qjBl1+Nw1tDnHIC0+v9XmeZERQfCds9Kp1UivfReoYImntBCgLtNyqRYrSu8csJCt7E1oY8QK6WP1vfYgAQ2taGyS9+g7FHyyf5VY2vH3oWzzbqzxjsSLAv3zEQSm1LzSw9Pvc8iwasFyUMBOPj31CKQYTXyX8KpJTr0Zb7oqMauBE5LVwxZhlcJHbj0FsMbF/+GRjvgexymCi3bHmwGQ6FEADNd0RkhdQ== username@domainname

U mnie działa to, że:

• Zatrzymano instancję ec2
• odłącz głośność
• dołączyć wolumin do starej instancji przy użyciu tego samego klucza i udało się nawiązać połączenie SSH
• zamontuj wolumin w jakimś folderze tymczasowym
• sprawdził plik w katalogu punkt_podłączenia / home / ec2-user / .ssh / authoris_keys
  • Idealnie, ten plik musi zawierać nasze kluczowe informacje, ale dla mnie ten plik był pusty
• skopiował stary plik Authorized_keys instancji do nowo zamontowanego woluminu
• odmontuj urządzenie
• dołącz ponownie do oryginalnej instancji ec2
• uruchom go i pozwól mu przejść kontrolę stanu

Tym razem to działa dla mnie. Ale nie wiem, dlaczego na początku nie ma informacji o moim kluczowym pliku, gdy instancja została uruchomiona. Sprawdź też ten link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html#TroubleshootingInstancesConnectingMindTerm

W moim przypadku problem był taki, że podczas generowania kluczy ssh celowo zmieniłem domyślne katalogi kluczy. Więc zamiast używać lokalizacji ~ / .ssh / authoris_keys, którą wybrałem ~/home/user/folder1/.ssh/authorized_keys, aby te zmiany zadziałały, miałem dokonać tych samych zmian co do nowej lokalizacji w tym pliku /etc/ssh/sshd_config. Ale dopóki nie zdaję sobie z tego sprawy, wypróbowałem już kilka rozwiązań sugerowanych przez inne osoby, w tym ustawienie uprawnień do folderu domowego na 700i katalogu .ssh na 600.

Kroki, aby naprawić montowanie roota (które wykonałem, gdy zmieniłem uprawnienia w folderze ec2-user i pliku klucza autoryzacji) Ten proces będzie podobny do odłączania i podłączania pendrive'a

Poniżej znajduje się kilka innych scenariuszy, które możesz napotkać -

1. Używasz klucza prywatnego SSH, ale odpowiadający mu klucz publiczny nie znajduje się w pliku Authorized_keys.
2. Nie masz uprawnień do pliku authorised_keys.
3. Nie masz uprawnień do folderu .ssh.
4. Twój plik Authorized_keys lub folder .ssh ma nieprawidłową nazwę.
5. Twój plik Authorized_keys lub folder .ssh został usunięty.

Kroki, aby je naprawić

• Zatrzymaj problematyczną instancję Ec2
• Odłącz wolumin główny (/ dev / sda1)
• Utwórz instancję ec2 lub użyj działającej
• Zamontuj odłączony wolumin (/ dev / sdvf) do nowej instancji ec2

Teraz po zalogowaniu się do nowego ec2 uruchom poniższe kroki

• Polecenie Lsblk - wyświetla listę wszystkich dostępnych montowań
• Wybierz wartość montowania, którą odmontujesz z powodującej problem instancji
• Jako ec2-user uruchom „sudo mount / dev / mapper / rootvg-home / mnt” sudo mount /dev/mapper/rootvg-home /mnt
• Następnie zmień katalog na / mnt
• Wprowadź wszystkie niezbędne zmiany

Teraz rozwiązaliśmy problem, który napotkaliśmy. Głównie może to być problem z uprawnieniami użytkownika - Umount / mnt, aby go odmontować - Teraz przejdź do konsoli i wskaż wolumin dołączony do nowej instancji i odłącz go - Po odłączeniu podłącz go do nowego woluminu jako / dev / sda1

Powiedziawszy to, powinieneś być w stanie pomyślnie się zalogować

Z mojego doświadczenia wynika, że ​​należy generować klucze z kitu, a nie po stronie linuxa. Ponieważ klucz będzie w starym formacie PEM. W każdym razie, tylko moja sugestia. Zrobiłem poniższe kroki i dobrze współpracowałem ze mną i moim zespołem.

1. Wygeneruj parę kluczy za pomocą PuTTYGen.exe na swoim lokalnym (typ: RSA, długość: 2048 bitów).

2. Zapisz klucz prywatny / publiczny jako pliki „ id_rsa.ppk / id_rsa.pub ” na swoim lokalnym komputerze.

3. Utwórz plik „Authorized_keys” na swoim lokalnym komputerze, a następnie wprowadź klucz publiczny w „ id_rsa.pub ” do „ Authorized_keys ”. Pamiętaj, że treść musi zaczynać się od „ ssh-rsa ” i tylko w jednej linii .

4. Użyj WinScp (lub komendy putty), aby skopiować " author_keys & id_rsa.pub " z twojego lokalnego do twojego linux-user-home " /home/$USER/.ssh/ ".

5. Uruchom te polecenia:

   chmod 700 .ssh

   chmod 600 .ssh / autoryzowane_klucze

   chown $ UŻYTKOWNIK: $ UŻYTKOWNIK .ssh -R

6. Przetestuj ustawienie połączenia, ładując klucz prywatny „ id_rsa.ppk ” w profilu PuTTY.exe, a następnie kliknij przycisk Otwórz (podaj hasło, jeśli zostało).

sprawdź swój klucz, powinien to być klucz rsa (id_rsa.pub) dzisiaj, a nie klucz dss (id_dsa.pub), użyj puttygen 0.70 i wybierz RSA na typ klucza do wygenerowania, zastąp klucz publiczny na hoście ~ /. ssh / authoris_keys

Po dodaniu klucza zaloguj się tak ec2-user, jakbyś korzystał z maszyny Amazon Linux

W moim przypadku był to zły użytkownik: przypisanie do grupy. Rozwiązałem ustawianie odpowiedniego użytkownika i grupy:

sudo chown [user]:[group] -R /home/[user]

Innym powodem może być BOM UTF-8 w authorized_keyspliku.