Ueberschrift

• Urspruenglicher Autor: Ramon Kukla
• Urspruengliches Datum: 04.03.2011

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.

Zurück zur Uebersicht