ssh-copy-id funktioniert nicht

Ich versuche unter CentOS 5.4 ein passwortloses SSH-Login einzurichten:

1. Ich habe auf dem Client einen öffentlichen RSA-Schlüssel generiert.
2. ssh-copy-id vom client zum server.
3. Verified ~ / .ssh / authorized_keys enthält den Client-Schlüssel.

Der Client hat weiterhin nach dem Kennwort gefragt. Was habe ich verpasst?

Vielen Dank.

BEARBEITEN: überprüft ssh_config und Berechtigungen wie empfohlen. Dies ist die Debug-Info vom Client:

debug2: key: /home/saguna/.ssh/identity ((nil))
debug2: key: /home/saguna/.ssh/id_rsa (0x2b31921be9a0)
debug2: key: /home/saguna/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 192.168.1.75.
debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug1: Unspecified GSS failure.  Minor code may provide more information
Unknown code krb5 195

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/saguna/.ssh/identity
debug3: no such identity: /home/saguna/.ssh/identity
debug1: Offering public key: /home/saguna/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Trying private key: /home/saguna/.ssh/id_dsa
debug3: no such identity: /home/saguna/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
saguna@192.168.1.75's password: 

9/10 Mal, weil ~ / .ssh / authorized_keys nicht im richtigen Modus ist.

chmod 600 ~/.ssh/authorized_keys

Checken Sie in / etc / ssh / sshd_config ein, um die Authentifizierung mit einem Schlüssel zu ermöglichen. Sie sollten so etwas in sich haben und sicherstellen, dass die Zeilen nicht kommentiert werden:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys

PS: Vergiss nicht, sshd nach dem Ändern der Datei neu zu starten (/etc/init.d/sshd restart)

Ich stellte fest, dass das Problem bei meinem System darin bestand, dass das Benutzerverzeichnis (/ home / username) mit den falschen Berechtigungen ausgestattet war. Es war drwxr-x-w-und musste sein drwxr-xr-x(mit schriftlicher Genehmigung nur für den Eigentümer). Die Lösung war, chmod zu verwenden:

sudo chmod 0755 /home/username

Ich bin hier kein Experte, aber auch auf ein solches Problem gestoßen, hier sind meine zwei Cent zusätzlich zu all den anderen Vorschlägen.

Manchmal wird ssh-copy-idder falsche Schlüssel auf den Remote-Server kopiert (dies kann vorkommen, wenn Sie mehrere Schlüssel haben und / oder nicht standardmäßige Namen für Schlüsseldateien verwenden) oder Ihr Authentifizierungsagent ist falsch konfiguriert.

Hier ist ein Zitat aus den Manpages :

Wenn die Option -i angegeben ist, wird die Identitätsdatei (standardmäßig ~ / .ssh / id_rsa.pub) verwendet, unabhängig davon, ob sich in Ihrem ssh-agent Schlüssel befinden. Wenn andernfalls ssh-add -L eine Ausgabe bereitstellt, wird diese der Identitätsdatei vorgezogen.

Grundsätzlich möchten Sie Folgendes überprüfen:

• Ihr Systemauthentifizierungsagent (normalerweise ssh-agent) erkennt die Schlüssel, die Sie verwenden möchten ( ssh-add -LAusgabe prüfen )
  • Wenn Sie den gewünschten Schlüssel nicht sehen, fügen Sie ihn mit ssh-add hinzu
• Sie haben ssh-copy-iddenselben Schlüssel auf den Remote-Computer kopiert (melden Sie sich einfach mit dem Kennwort beim Remote-Server an und überprüfen Sie den Inhalt von ~/.ssh/authorized_keys).
  • Wenn Sie den gewünschten Schlüssel nicht auf dem Remote-Server sehen, können Sie implizit angeben, ssh-copy-idwelchen Schlüssel Sie kopieren möchten:ssh-copy-id -i ~/.ssh/some_public_key

Ich hoffe, das hilft.

Das häufigste Problem sind ungültige Berechtigungen auf der Serverseite. Es darf keine Ihr Home - Verzeichnis, ~/.sshund ~/.ssh/authorized_keysbeschreibbar sind von jedermann , aber sie (insbesondere dürfen sie nicht seine Gruppe beschreibbare).

Wenn dies nicht das Problem ist, ssh -vvv serverrufen Sie die Kundenansicht der Konversation auf. Stellen Sie insbesondere sicher, dass der Client den Schlüssel mit dem Server versucht.

Zusätzlich zu all dem kann man immer die sshd-Protokolldatei überprüfen:

/var/log/auth.log

Ich habe die anderen Fixes ausprobiert, aber festgestellt, dass ich das Home-Verzeichnis ändern musste, damit andere keine Schreibrechte haben. Das Home-Verzeichnis war 777. Ich habe es in 755 geändert und es hat funktioniert.

In meinem Fall enthielt / etc / ssh / sshd_config den folgenden Parameter:

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys2

Da ssh-copy-id eine Datei mit dem Namen authorized_keys erstellt hat, musste ich den Eintrag auf den neuen Namen ändern. Weitere Informationen zu veralteten authorized_keys2

Als Ergänzung zu Omer Dagans Antwort für neuere CentOS 7 verwenden Sie:

journalctl -f -u sshd

zum Betrachten der sshd-Protokolle auf dem Server.

Das Problem war, dass RSAAuthentication in / etc / ssh / ssh_config deaktiviert war