Klucz SSH akceptowany przez hosta, ale klient się rozłącza

Helo,

Mam problem z SSH po instalacji Fedory 23.

Kiedy nie chcę połączyć się ze zdalnym hostem za pomocą klucza prywatnego, mój host znajduje klucz:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Ale jak widzisz, mój klient sam się rozłącza

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Mogę połączyć się z moim hostem za pomocą Kit w systemie Windows za pomocą tego samego klucza prywatnego i mogę połączyć się z telefonem za pomocą innego klucza prywatnego.

Masz jakiś pomysł ?

/ etc / ssh / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

Dziękuję Ci

Edycja: mogę połączyć się za pomocą hasła

Przede wszystkim istnieje wiele, bardzo dobrze napisanych, szczegółowych dokumentów na temat konfiguracji lub konfiguracji uwierzytelniania opartego na kluczu publicznym, które są dostępne online. Rzuć okiem na jeden z nich i sprawdź, czy wszystko przestrzegałeś poprawnie. Oto jeden Więc nie powtórzę tego ponownie.

Podstawową koncepcją jest (skopiowane stąd ):

Uwierzytelnianie oparte na kluczach wykorzystuje dwa klucze, jeden klucz „publiczny”, który każdy może zobaczyć, i drugi klucz „prywatny”, który może zobaczyć tylko właściciel. Aby bezpiecznie komunikować się za pomocą uwierzytelniania opartego na kluczach, należy utworzyć parę kluczy, bezpiecznie przechowywać klucz prywatny na komputerze, z którego chcesz się zalogować, i przechowywać klucz publiczny na komputerze, na którym chcesz się zalogować.

Teraz z opublikowanego dziennika debugowania:

• Wygląda na to, że w grę wchodzą dwóch różnych użytkowników. /home/theo/.ssh/authorized_keysa /home/tbouge/.ssh/id_rsa. Czy próbujesz zalogować się jako jeden użytkownik do katalogu domowego innego użytkownika?
• Błąd Postponed publickey for theo..oznacza, że ​​próbowano niepożądanej metody uwierzytelnienia przed metodą klucza publicznego. SSH wypróbuje każdą metodę uwierzytelniania, która jest włączona w konfiguracji, jedna po drugiej. W twoim przypadku masz GSSAPIAuthentication yeswłączone to, czego nie używasz. Możesz to bezpiecznie wyłączyć, robiąc to GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodnajprawdopodobniej nie może przetworzyć pliku klucza prywatnego (problem z uprawnieniami do pliku lub nazwą). SSH jest bardzo wrażliwy na uprawnienia do katalogów i plików na komputerach lokalnych i zdalnych. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Upewnij się więc, że twoje są ustawione poprawnie. Zobacz: /unix/131886/ssh-public-key-wont-send-to-server

• Co do trzeciego błędu: Permission denied (public key).jest kilka rzeczy do sprawdzenia.

  • Zła nazwa użytkownika
  • Zła para kluczy

  • Niewłaściwy host docelowy

    • Oto więcej szczegółów: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

Następująca część jest nieco myląca:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Aby to lepiej zrozumieć, przejdźmy przez proces uwierzytelniania krok po kroku, jak opisano tutaj w digitalocean :

1. Klient zaczyna od wysłania identyfikatora pary kluczy, z którą chciałby się uwierzytelnić na serwerze.
2. Kontrola serwera to plik autoryzowanych_kluczy konta, na które klient próbuje się zalogować, aby uzyskać identyfikator klucza.
3. Jeśli w pliku zostanie znaleziony klucz publiczny z pasującym identyfikatorem, serwer generuje liczbę losową i używa klucza publicznego do zaszyfrowania numeru.
4. Serwer wysyła do klienta zaszyfrowaną wiadomość.
5. Jeśli klient faktycznie ma powiązany klucz prywatny, będzie mógł odszyfrować wiadomość przy użyciu tego klucza, odsłaniając oryginalny numer.
6. Klient łączy odszyfrowaną liczbę ze współdzielonym kluczem sesji, który jest używany do szyfrowania komunikacji, i oblicza wartość skrótu MD5 tej wartości.
7. Klient wysyła następnie ten skrót MD5 z powrotem do serwera jako odpowiedź na wiadomość z zaszyfrowanym numerem.
8. Serwer używa tego samego wspólnego klucza sesji i oryginalnego numeru, który wysłał do klienta, aby samodzielnie obliczyć wartość MD5. Porównuje własne obliczenia z obliczeniami odesłanymi przez klienta. Jeśli te dwie wartości są zgodne, oznacza to, że klient był w posiadaniu klucza prywatnego i klient został uwierzytelniony.

W twoim przypadku, jak widać, komputer zdalny tylko zaakceptował twój public key, zaszyfrował pakiet tym kluczem i odesłał go z powrotem do komputera klienckiego. Teraz komputer kliencki musi udowodnić, że ma do tego prawo private key. Przy użyciu tylko odpowiedniego klucza prywatnego może odszyfrować otrzymaną wiadomość i odesłać odpowiedź. W takim przypadku klient tego nie robi, a proces uwierzytelnienia kończy się bez powodzenia.

Mam nadzieję, że pomoże ci to zrozumieć problemy i je rozwiązać.

Czy uprawnienia do plików ssh są prawidłowe?

.ssh Folder -> 700

klucz publiczny -> 644

klucz prywatny -> 600

Sprawdź także użytkownika i grupę

Mówisz, że masz ten sam klucz na komputerze z systemem Windows; czy jesteś pewien, że plik klucza prywatnego, który masz na komputerze z systemem Linux, jest poprawny? Być może klucz prywatny ma format kitu, którego ssh nie rozumie łatwo. W każdym razie, jeśli wstawię niepoprawny lub niepoprawny plik klucza prywatnego, otrzymam dokładnie ten sam błąd, który masz.

Aby rozwiązać problem, bardziej odpowiednie byłoby wygenerowanie nowego klucza na komputerze z systemem Linux zamiast ponownego użycia klucza z innego komputera. Możesz po prostu dodać nowy klucz publiczny do pliku autoryzowanego_kluczy na hoście, a następnie możesz użyć zarówno klucza Windows z Windows, jak i nowego klucza Linux z Fedory.

twój problem wydaje się dość powszechny i ​​jasne, że tak mówię.

 Permission denied (publickey).

czy to coś dla ciebie znaczy? dla mnie to wiele dla mnie znaczy.

czy możesz sprawdzić po stronie serwera, czy masz selinux runnin w trybie wymuszonym? jeśli nie, powiedz mi do jakiego trybu działa selinux.

Ponadto, jeśli możesz wykonać jeszcze jedną próbę i przechwycić dzienniki kontroli tej próby i opublikować tutaj, na pewno powie nam, dlaczego:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Problem dotyczący uprawnień jest jasny, ale nie dotyczy uprawnień do plików :-)

Wygląda na to, że problem (w moim przypadku ...) był spowodowany rodzajem klucza.

Właśnie rozwiązałem ten problem, dodając następujące informacje do ~/.ssh/configpliku lokalnego (komputer kliencki Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Chociaż dodałem tę linię zarówno do pliku konfiguracyjnego serwera, jak i klienta, tylko strona klienta zrobiła różnicę. Należy pamiętać, że należy zezwolić 600na odczyt pliku konfiguracyjnego.

Nie wiem, czy ktoś jeszcze ma ten problem, ale w końcu rozwiązałem go dla mojej jednej maszyny (laptopa), w której występował problem. Wydaje mi się , że wiem, co ostatecznie to rozwiązało, i zostawiam tutaj informacje w nadziei, że pomoże to każdemu, kto może jeszcze się z tym spotkać - a także, aby ktoś miał nadzieję sprawdzić moje rozwiązanie i potwierdzić, że tak naprawdę Rozwiązać problem.

Jak się okazuje, problem nie dotyczył (dla mnie) SSH, ale sposobu konfiguracji kluczy przez PAM. Konfiguracja w /etc/pam.dbyła nieaktualna (chociaż działała poprawnie przez Fedorę 22), w wyniku czego nie logowano się już [przy logowaniu], aby odebrać moje klucze $HOME/.ssh/. Uruchomienie tego polecenia:

# sudo authconfig --updateall

poprawnie przebudował konfigurację /etc/pam.d. Przy następnym restarcie, po zalogowaniu, kiedy po raz pierwszy próbowałem wylogować się na mój serwer, okno dialogowe poprosiło mnie o wpisanie hasła dla mojego klucza ssh ( $HOME/.ssh/id_rsa). Zrobiłem to, zaznaczyłem pole „Automatycznie odblokuj przy logowaniu” i voila! Moja zdolność do ssh out z laptopa została przywrócona.

tło

Wskazówka, która doprowadziła mnie do rozwiązania tego problemu, pojawiła się, gdy zaimportowałem klucz RSA z zewnętrznego źródła. (Klucz USB I nosić z moim kluczem „Zdalny dostęp” dla mojej domowej sieci. Wyłączyłem PasswordAuth do moich wychodzącym na zewnątrz serwerów lat temu po włamaniem.) Po ssh-add-ing ŻE klucz RSA, w przeciwieństwie do jednego siedzącego $HOME/.ssh/id_rsa, został bez problemu zaakceptowany przez zdalny serwer.

Wtedy skończyło się na tym, co powinno już zbędne ssh-add, aby odebrać $HOME/.ssh/id_rsa. Zauważyłem, że po tym, ssh-add -lzawierałem dwa wpisy dla tego samego klucza:

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

Zauważ, że jeden z dwóch wpisów nie pokazuje identyfikatora klucza, a jedynie nazwę klucza prywatnego pasującą do jego podpisu publicznego. Tak jakby klucz prywatny nie był tak naprawdę odblokowany przez menedżera kluczy.

Uważam, że dokładnie tak się działo, a PAM przekazał „złe klucze” agentowi SSH, który nie został odblokowany za pomocą hasła. Tak więc, gdy ssh próbował uwierzytelnić się za pomocą klucza, tak naprawdę nie miał (odblokowanej) prywatnej połowy pary kluczy, a zatem uwierzytelnienie nie powiodło się.

Ten ostatni bit jest przypuszczeniem, ale niezależnie od tego, czy ktoś ma problemy z tym, że klucze ssh nie są akceptowane przez zdalne hosty (tam, gdzie kiedyś były) po aktualizacji do F23, warto spróbować odbudować /etc/pam.d/katalog przy użyciu authconfig.

Sprawdź uprawnienia do katalogu domowego użytkownika. To ważne. Musi mieć 755. 700 lub 770 nie będzie działać.

W twojej ssh_config, spróbuj odkomentowanie i / lub dodanie / usunięcie / dodanie albo do Cipher, Ciphersalbo MACslinii (S).

Wydaje mi się, że sshdszuka pewnego rodzaju szyfru, który nie jest uwzględniony w żądaniu, który można dodać, konfigurując go w swoim ssh_config.

... i zakładam, że przypadkiem nie PubkeyAuthenticationustawiłeś się nona zdalnym serwerze, ponieważ to na pewno spowodowałoby to niepowodzenie.