scponly: Failed publickey - Wieso?

[TheAnimal]

Hallo Zusammen,
ich habe einen Suse 10.3 Server. Auf dem möchte ich einem User den Login per Key ohne Passwort ermöglichen.
Der User hat mir dafür seinen Public-Key gegeben und ich habe diesem auf meinem Server hinterlegt. Er hat sich versucht, mit seinem Private-Key einzuloggen, dass hat auch funktioniert.

Jetzt war ich im Urlaub und habe danach erfahren, dass es nur für ein paar Tage funktioniert hat, jetzt nicht mehr. Er muss wieder ein Passwort eingeben.

Ich habe mir ein Keypaar (ohne Passwort) mittels Putty erstellt und damit versucht mich einzuloggen. Leider klappt das auch nicht mehr. Ich bekomme die Meldung

Server refused our key

Wenn ich jetzt einen sshd mittels "/usr/sbin/sshd -D -p8022 -d" starte und mich über Putty versuche einzuloggen kommt folgendes

debug1: sshd version OpenSSH_4.6p1
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-D'
debug1: rexec_argv[2]='-p8022'
debug1: rexec_argv[3]='-d'
debug1: Bind to port 8022 on ::.
Server listening on :: port 8022.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 84.46.7.180 port 3123
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.59
debug1: no match: PuTTY_Release_0.59
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.6
debug1: permanently_set_uid: 71/65
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client->server aes256-ctr hmac-sha1 none
debug1: kex: server->client aes256-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user web5 service ssh-connection method none
debug1: attempt 0 failures 0
Failed none for web5 from 84.46.7.180 port 3123 ssh2
debug1: userauth-request for user web5 service ssh-connection method publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 1008/100 (e=0/0)
debug1: trying public key file /srv/ftp/merch/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 1008/100 (e=0/0)
debug1: trying public key file /srv/ftp/merch/.ssh/authorized_keys
debug1: restore_uid: 0/0
Failed publickey for web5 from 84.46.7.180 port 3123 ssh2
Received disconnect from 84.46.7.180: 13: Unable to authenticate
Das Key-File hat die Rechte 644. Ich weiss nicht, wieso er den Key nicht mehr erkennt. Woran kann es liegen?

[MiGo]

Ich habe mir ein Keypaar (ohne Passwort) mittels Putty erstellt und damit versucht mich einzuloggen. Leider klappt das auch nicht mehr.
Wenn ich mich da richtig erinnere, müssen die Schlüssel, die mit Putty erstellt werden, erst in ein passendes Format umgewandelt werden, um in die ~/.ssh/authorized_keys eingetragen zu werden.

[TheAnimal]

Weisst du auch, wie ich die umwandel?

[marce]

ohne alles gelesen zu haben - evtl. wird Dir hier weitergeholfen:
http://www.cs.uwaterloo.ca/cscf/howto/ssh/public_key/

[TheAnimal]

@marce
Danke. Ich werde mir das mal anschauen.

Ich habe jetzt mal auf dem Server einen Key für root erstellt. Diesen habe ich auf meinem Windows-Rechner in Putty imporitert. Das funktioniert. Ich kann mich mit dem Key auf dem Server einloggen.
Das gleiche habe ich für den betreffenden User web5 (habe kein Confxx drauf) gemacht. Da funktioniert das nicht. Ich bekomme vom Server nur

Server refused our key
Verstehe das nciht wirklicht. Mit dem root-Key klappt es, mit dem anderen nicht.

[Roger Wilco]

Hinweise unter http://sublimation.org/scponly/wiki/index.php/FAQ#How_do_I_turn_on_logging.3F befolgen und dann die Logs ansehen.