Aus gegebenem Anlass etwas „Wiederverwertung“ :). Die Tage wurde ich angesprochen, da ein Kollege ein Problem hatte. Es ging darum, dass eine SSH-Verbindung mit Authentifizierung via SSH-Key nicht funktionieren wollte. Im Detail stellte es sich so dar, dass der Client eine Kennwortabfrage brachte. Frage war nun, was hier der Grund fuer den Effekt war. Also haben wir uns erst mal an den Client gesetzt und die loebliche, aber nur selten verwendete Option -v, genutzt.
ramon@client ~/.ssh $ ssh -vvv ramon@server debug1: Next authentication method: publickey debug1: Trying private key: /home/ramon/.ssh/identity debug3: no such identity: /home/ramon/.ssh/identity debug1: Trying private key: /home/ramon/.ssh/id_rsa debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug3: Wrote 640 bytes for a total of 1767 debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/ramon/.ssh/id_dsa debug3: no such identity: /home/ramon/.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 ramon@server's password:
Hier kann man prima sehen, dass versucht wird mit id_dsa sich gegenueber dem Server zu authentifizieren. Allerdings schlaegt das fehl. Das sieht man daran, dass nach einem Kennwort gefragt wird. Schauen wir also mal wie es sich auf dem Server darstellt. Um den laufenden Betrieb nicht zu stoeren starten wir einen weiteren SSH-Daemon inklusive Debug-Option der auf Port 24 lauscht.
root@server:/# /usr/sbin/sshd -p 24 -ddd
Nun versuchen wir uns noch einmal via ssh -p 24 user@server am Server anzumelden und schauen, was der Server ausgibt.
debug1: trying public key file /home/ramon/.ssh/authorized_keys debug1: fd 4 clearing O_NONBLOCK Authentication refused: bad ownership or modes for file /home/ramon/.ssh/authorized_keys debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/ramon/.ssh/authorized_keys2 debug1: restore_uid: 0/0 Failed publickey for ramon from 10.0.0.194 port 41962 ssh2
Hier kann man nun prima sehen warum der Zugriff nicht wie geplant funktioniert. Der Ausloeser ist die falsch gesetzte Berechtigung auf der authorized_keys. Entweder setzt man nun also die Rechte „korrekt“, ausser dem Owner darf niemand W(rite) haben, oder man setzt StrictMode no. Letzteres ist allerdings nicht zu empfehlen. Wer interessiert ist findet die Pruefung auch im Quellcode von OpenSSH in der auth.c. Die Funktion nennt sich da secure_filename.