ssh monituje o podanie hasła pomimo ssh-copy-id

Od pewnego czasu używam uwierzytelniania za pomocą klucza publicznego na zdalnym serwerze do zdalnego używania powłoki, a także do montowania sshfs. Po wymuszeniu umount katalogu sshfs zauważyłem, że ssh zaczął mnie pytać o hasło. Próbowałem usunąć zdalne .ssh / uprawnione_klucze z dowolnej wzmianki o maszynie lokalnej i wyczyściłem maszynę lokalną z odniesień do maszyny zdalnej. Następnie powtórzyłem swój ssh-copy-id, poprosił mnie o hasło i wrócił normalnie. Ale oto, kiedy ssh do zdalnego serwera nadal pojawia się monit o hasło. Jestem trochę zdezorientowany, co to może być problem, jakieś sugestie?

sshd dziwnie się czuje z uprawnieniami do $ HOME, $ HOME / .ssh (oba katalogi) i do $ HOME / .ssh / uprawnione_ klucze.

Jedno z moich pudeł linuksowych zakończyło się uprawnieniami drwxrwxrwx do mojego katalogu $ HOME. Arch Arch Linux absolutnie nie zalogowałby się przy użyciu kluczy publicznych, dopóki nie usunę uprawnień „w” dla grupy, innych w moim katalogu $ HOME.

Spróbuj, aby $ HOME i $ HOME / .ssh / miały bardziej restrykcyjne uprawnienia dla grupy i innych. Sprawdź, czy to nie pozwala sshd robić swoich rzeczy.

Potrzebne są następujące uprawnienia:

• .sshFolderu:700 (drwx------)
• Klucz publiczny: 644 (-rw-r--r--)
• Klucz prywatny: 600 (-rw-------)

Ostatnio doświadczyłem również tego problemu.

Zostało to poprawione poprzez zmianę uprawnień do $HOMEkatalogu. Jednak samo uruchomienie chmod g-w ~/nie rozwiązało problemu. Oprócz tego chmod g-w ~/musiałem również zmodyfikować uprawnienia othersdo $HOMEkatalogu, uruchamiającchmod o-wx ~/

Razem:

chmod g-w ~/
chmod o-wx ~/

Zauważ, że nie jestem pewien, czy o-xbyło to konieczne, po prostu uruchomiłem to jako środek ostrożności.

Zmiana uprawnień do folderu ~ / .ssh rozwiązała mój problem zgodnie z tym postem na Super User SE .

Czy problem występuje również przy logowaniu równoległym, tj. Jeśli próbujesz zamontować sshfs mając otwartą sesję ssh? Jeśli nie, to zgaduję, że masz zaszyfrowany katalog domowy? W takim przypadku $HOME/.ssh/authorized_keysstaną się użyteczne na zdalnym komputerze dopiero po pierwszym logowaniu (przy użyciu hasła).

Sprawdź https://help.ubuntu.com/community/SSH/OpenSSH/Keys#Trou Rozwiązywanie problemów, aby uzyskać wyjaśnienie i wymagane obejście.

Zamieściłbym to jako komentarz, ale prawdopodobnie byłoby to zbyt długie. Chciałem tylko dodać, że ssh-copy-idpróbuje wysłać klucz publiczny z /.sshlokalizacji w twoim $HOMEfolderze.

Jeśli próbujesz sshjako root za pomocą klucza publicznego (zapisać komentarze związane z bezpieczeństwem), ssh-copy-idmożesz próbować zalogować się przy użyciu niewłaściwego klucza publicznego, jeśli twoja $HOMEzmienna jest ustawiona na cokolwiek innego niż /root(na przykład na katalog domowy zwykłego użytkownika ), dlatego użytkownik root byłby monitowany, ponieważ klucz publiczny root nie jest zainstalowany w systemie zdalnym.

Aby określić dokładny klucz publiczny, możesz użyć następującego jednowierszowego:

pub="$(cat /root/.ssh/id_rsa.pub)"; ssh user@remotehost "echo $pub >> .ssh/authorized_keys; chmod 700 .ssh; chmod 600 .ssh/authorized_keys"

Kilka razy spotkałem się z tym scenariuszem (również dziś rano) i pomyślałem, że spróbuję włożyć moje 2 centy, na wypadek, gdyby ktoś znalazł się w takiej samej sytuacji.

Jak wspomnieli inni współautorzy, jest to prawdopodobnie problem z pozwoleniem.

Najlepszym sposobem zdiagnozowania tego jest zrestartowanie demona SSH na zdalnym serwerze z włączoną opcją debugowania - zwykle jest to opcja „-d”. Komunikat demona OpenSSH jest bardzo wyraźny. Na przykład zobaczysz wiadomości takie jak:

Authentication refused: bad ownership or modes for directory /some/path

Powodem, dla którego klucz publiczny nie przetrwał po ponownym uruchomieniu, było zaszyfrowanie katalogu domowego mojego serwera. (robisz to podczas instalowania serwera)

Innym możliwym problemem jest to, że serwer nie obsługuje algorytmu klucza. W moim przypadku w sshddziennikach ( /var/log/auth.logw moim przypadku) znalazłem następujące komunikaty :

userauth_pubkey: unsupported public key algorithm: ssh-ed25519 [preauth]

W takim przypadku musisz włączyć obsługę tego algorytmu w sshdkonfiguracji (co może wymagać aktualizacji do nowszej sshdwersji) lub zmienić klucz na algorytm obsługiwany przez urządzenie sshd, z którym próbujesz się połączyć .

Ponieważ te pytania pojawiają się wśród pierwszych wyników wyszukiwania w Google dla tego zachowania, dodam również moje rozwiązanie:

W moim przypadku nie było to nic związanego z uprawnieniami. Z jakiegokolwiek powodu (nie zadałem sobie trudu, aby dowiedzieć się z jakiego powodu, ponieważ znalazłem szybką poprawkę) podczas wykonywania polecenia ssh program nie szukał odpowiedniego pliku tożsamości. Jednym z rozwiązań było ręczne dodanie na zdalnym serwerze klucza SSH, którego program SSH próbował użyć. Możesz zaobserwować, co robi program SSH podczas wykonywania polecenia, dodając do polecenia -v:

ssh -v username@your-host-ip-or-domain 

Następnie wystarczy pobrać na swój komputer lokalny dowolny klucz publiczny, dla którego program SSH próbuje znaleźć plik tożsamości / klucz prywatny, na przykład na komputerze Mac:

cat ~/.ssh/id_rsa.pub

... i dodaj go do pliku autoryzowanego_kluczy pilota w:

~/.ssh/authorized_keys

Innym, w moim przypadku lepszym rozwiązaniem było dodanie niestandardowego hosta do mojego lokalnego pliku konfiguracyjnego ssh. Na moim komputerze Mac jest to:

/Users/my-user-name/.ssh/config

Tutaj możesz dodać na przykład coś takiego:

Host mynewserver
        HostName some.IP.number.or.domain
        Port 20000 #if custom port is used and not the default 22
        User the_root
        PreferredAuthentications publickey
        IdentityFile ~/.ssh/id_rsa_for_my_new_server

Następnie wystarczy wykonać:

ssh mynewserver

... i Voilà