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

28

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?

Aliud Alius
źródło
1
serverfault.com/questions/208181/... Nie jestem pewien, co polityka Stack Exchange Network na całym duplikatów stron jest, ale nie wydaje mi się, że cross-posting pytanie byłoby pomocne.
ephemient
Jeśli zaznaczyłeś, że tylko możesz pisać do ~, ~/.ssha także ~/.ssh/authorized_keysuruchamiać ssh -vvv server.example.comi raportować dane wyjściowe (jeśli chcesz, anonimizuj nazwy hosta i użytkownika). Jeśli masz dostęp do roota na serwerze, spójrz na wpisy dziennika utworzone podczas próby zalogowania się za pomocą klucza publicznego.
Gilles „SO- przestań być zły”

Odpowiedzi:

32

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.

Bruce Ediger
źródło
4
Tak. ssh-copy-idpowinien był zadbać o uprawnienia ~/.sshi ~/.ssh/authorized_keys, ale także upewnić się, że sam katalog domowy nie nadaje się do zapisu grupowego.
Gilles „SO- przestań być zły”
7
To było dla mnie. Użyłem ssh-copy-id do przesłania klucza RSA i wciąż otrzymywałem monit. Uruchamianie chmod g-w homedirna zdalnym serwerze działało jak urok.
Ben Kreeger,
9

Potrzebne są następujące uprawnienia:

  • .sshFolderu:700 (drwx------)
  • Klucz publiczny: 644 (-rw-r--r--)
  • Klucz prywatny: 600 (-rw-------)
Sagar Naik
źródło
5

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.

izzy.artistic
źródło
0

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.

fheub
źródło
0

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.

rubinorails
źródło
0

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
gerard lapeche
źródło
Nie nazwałbym tego komunikatu „bardzo wyraźnym”. Mówi bardzo niejasno, czego należy szukać (niepoprawne prawa własności i uprawnienia), ale nie mówi, który katalog lub plik należy sprawdzić, ani jakie powinny być prawidłowe ustawienia.
Urhixidur
0

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

dinbo
źródło
0

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

Florian Brucker
źródło
0

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à

Schurik
źródło