Hallo, ich möchte von meinem PC per ssh auf einen anderen PC einloggen. Auf beiden läuft Suse 9.1. Mir ist es bis jetzt noch nicht gelungen unter Verwendung von Protokoll Version 2 einzuloggen. Weiß jemand an was es liegen könnte? Ich habe mit ~/.ssh> ssh-keygen -t rsa die Schlüssel generiert und id_rsa.pub nach "authorized_keys" kopiert ~/.ssh> ll -rw------- 1 ralfk users 963 2005-10-20 21:44 id_rsa -rw-r--r-- 1 ralfk users 221 2005-10-20 21:44 id_rsa.pub -rw-r--r-- 1 ralfk users 0 2005-10-20 21:20 known_hosts ralfk@sweaty:~/.ssh> ll -rw------- 1 ralfk users 221 2005-10-20 21:40 authorized_keys ~> ssh -vvvvv sweaty OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to sweaty [192.168.0.6] port 22. debug1: Connection established. debug1: identity file /home/ralf/.ssh/identity type -1 debug3: Not a RSA1 key file /home/ralf/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/ralf/.ssh/id_rsa type 1 debug1: identity file /home/ralf/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8p1 debug1: match: OpenSSH_3.8p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 143/256 debug2: bits set: 505/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host sweaty debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host sweaty The authenticity of host 'sweaty (192.168.0.6)' can't be established. RSA key fingerprint is xxx. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. Gruß Ralf
Ralf Kleemann wrote at Thursday, October 20, 2005 11:12 PM
ralfk@sweaty:~/.ssh> ll -rw------- 1 ralfk users 221 2005-10-20 21:40 authorized_keys
Wenn das hier das ~/.ssh Verzeichnis des PC's ist, _auf den_ Du Dich einloggen willst, dann fehlt hier auf alles Fälle die id_rsa.pub. Der Inhalt des Public Key in der authorized_keys alleine reicht nicht. Beachte auch, dass id_rsa.pub "world readable" sein muss. HTH Beste Grüße, Markus
Hallo Markus, hallo Ralf, hallo Leute, Am Donnerstag 20 Oktober 2005 23:16 schrieb Markus Heidinger:
Ralf Kleemann wrote at Thursday, October 20, 2005 11:12 PM
ralfk@sweaty:~/.ssh> ll -rw------- 1 ralfk users 221 2005-10-20 21:40 authorized_keys
Wenn das hier das ~/.ssh Verzeichnis des PC's ist, _auf den_ Du Dich einloggen willst, dann fehlt hier auf alles Fälle die id_rsa.pub. Der Inhalt des Public Key in der authorized_keys alleine reicht nicht.
Das halte ich für ein Gerücht. (Und wenn es so wäre, würde es bei mehreren Einträgen in authorized_keys lustig. Welcher davon soll in id_rsa.pub stehen? ;-)
Beachte auch, dass id_rsa.pub "world readable" sein muss.
Auch das halte ich für ein Gerücht, da der sshd als root läuft. Um meine Behauptungen zu untermauern und die obigen Gerüchte zu widerlegen: cb@cboltz:~> ssh test@localhost Last login: Thu Oct 20 23:55:45 2005 from localhost Have a lot of fun... test@cboltz:~> ls -al .ssh insgesamt 16 drwx------ 2 test users 4096 2005-10-20 23:56 . drwxr-xr-x 26 test users 4096 2005-10-20 23:57 .. -rw------- 1 test users 1108 2005-10-20 23:56 authorized_keys -rw------- 1 test users 444 2004-12-27 21:13 known_hosts test@cboltz:~> Was sieht man an diesem Mitschnitt? - der Login erfolgt passwortlos [1] per SSH-Key. - in ~/.ssh des Zielusers gibt es keine id_*.pub. - Außerdem ist sowohl ~/.ssh als auch authorized_keys nur dem User zugänglich. - (known_hosts existiert, weil ich auch schon ausgehende SSH-Verbindungen mit diesem User aufgebaut hatte.) Zur weiteren Lektüre empfehle ich 10.3. Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? http://suse-linux-faq.koehntopp.de/q/q-ssh-keygen.html sowie je nach Interesse auch die anderen Fragen zu SSH. Gruß Christian Boltz [1] damit der SSH-Key nicht ungeschützt rumliegen muss, verwende ich den ssh-agent --
Ich komme ja nicht aus dem Norden, aber gilt da nicht dieser Spruch: "Hamburg ist das Tor zur Welt, aber Bremen hat den Schlüssel dazu." Stimmt. Aber damit können die nichts anfangen, weil Hamburg weltoffen ist :-) [> Martin Röhricht und Thorsten Körner in suse-linux]
On Thu, Oct 20, 2005 at 11:12:10PM +0200, Ralf Kleemann wrote:
The authenticity of host 'sweaty (192.168.0.6)' can't be established. RSA key fingerprint is xxx. Are you sure you want to continue connecting (yes/no)? no Host key verification failed.
User-Auth erfolgt erst nach der Host-Key Verification. Peter
Hallo Ralf, hallo Leute, Am Donnerstag 20 Oktober 2005 23:12 schrieb Ralf Kleemann:
Ich habe mit [...]
Deine Vorgehensweise scheint mir soweit korrekt zu sein.
~> ssh -vvvvv sweaty [...] debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host sweaty The authenticity of host 'sweaty (192.168.0.6)' can't be established. RSA key fingerprint is xxx. Are you sure you want to continue connecting (yes/no)? no Host key verification failed.
Du hast Dich (unter diesem User) vorher noch nie per SSH auf "sweaty" eingeloggt? Das ist der Grund, warum an dieser Stelle erstmal die Abfrage kommt, ob Du überhaupt zu diesem Rechner verbunden werden willst. Wenn Du bei "Are you sure you want to continue connection (yes/no)?" einfach mal yes eintippst, geht es weiter. Das ist nur einmal erforderlich, in Zukunft ist "sweaty" bekannt und diese Abfrage taucht nicht mehr auf. Gruß Christian Boltz -- Auf Windows 95 laufen so ziemlich alle Spiele. Für ernsthaftes Arbeiten sollte man aber zusätzlich ein Betriebssystem installieren.
Christian Boltz schrieb:
debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host sweaty The authenticity of host 'sweaty (192.168.0.6)' can't be established. RSA key fingerprint is xxx. Are you sure you want to continue connecting (yes/no)? no Host key verification failed.
Du hast Dich (unter diesem User) vorher noch nie per SSH auf "sweaty" eingeloggt? Das ist der Grund, warum an dieser Stelle erstmal die Abfrage kommt, ob Du überhaupt zu diesem Rechner verbunden werden willst.
Wenn Du bei "Are you sure you want to continue connection (yes/no)?" einfach mal yes eintippst, geht es weiter. Das ist nur einmal erforderlich, in Zukunft ist "sweaty" bekannt und diese Abfrage taucht nicht mehr auf.
wenn ich yes eingebe, wird in die /home/ralfk/.ssh/known_hosts die /etc/ssh/ssh_host_rsa_key.pub des Rechners in den ich mich einloggen will,kopiert und es wird das Password des Users Ralfk abgefragt. Das will ich aber nicht. Ich möchte, das der private Schlüssel in /home/ralfk/.ssh/ zum einloggen verwendet wird damit ich die Passphrase mit dem ssh-agent cachen kann. Ich habe inzwischen mit einem rsa1-key versucht: ~> ssh-keygen -t rsa1 Generating public/private rsa1 key pair. Enter file in which to save the key (/home/ralfk/.ssh/identity): Enter passphrase (empty for no passphrase): Aber damit fuktioniert es auch nicht. ralfk@sweaty:~/.ssh> ssh -vvv 192.168.0.1 OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.0.1 [192.168.0.1] port 22. debug1: Connection established. debug1: identity file /home/ralfk/.ssh/identity type 0 debug1: identity file /home/ralfk/.ssh/id_rsa type -1 debug1: identity file /home/ralfk/.ssh/id_dsa type -1 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8p1 debug1: match: OpenSSH_3.8p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 125/256 debug2: bits set: 540/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/ralfk/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug3: check_host_in_hostfile: filename /home/ralfk/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 0 for host 192.168.0.1 debug3: check_host_in_hostfile: filename /home/ralfk/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /home/ralfk/.ssh/known_hosts debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts debug2: no key of type 2 for host 192.168.0.1 The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is xxx Are you sure you want to continue connecting (yes/no)? no Host key verification failed. Gruß Ralf
Hallo Ralf, hallo Leute, Am Freitag, 21. Oktober 2005 22:45 schrieb Ralf Kleemann:
Christian Boltz schrieb: [...]
Wenn Du bei "Are you sure you want to continue connection (yes/no)?" einfach mal yes eintippst, geht es weiter. Das ist nur einmal erforderlich, in Zukunft ist "sweaty" bekannt und diese Abfrage taucht nicht mehr auf.
wenn ich yes eingebe, wird in die /home/ralfk/.ssh/known_hosts die /etc/ssh/ssh_host_rsa_key.pub des Rechners in den ich mich einloggen will,kopiert
Richtig.
und es wird das Password des Users Ralfk abgefragt.
Möglich, aber das sind zwei ganz verschiedene Dinge.
Das will ich aber nicht. Ich möchte, das der private Schlüssel in /home/ralfk/.ssh/ zum einloggen verwendet wird damit ich die Passphrase mit dem ssh-agent cachen kann. [...] Aber damit fuktioniert es auch nicht.
ralfk@sweaty:~/.ssh> ssh -vvv 192.168.0.1 [...] debug1: identity file /home/ralfk/.ssh/identity type 0
Der Key wird also gefunden. [...]
The authenticity of host '192.168.0.1 (192.168.0.1)' can't be established. RSA key fingerprint is xxx Are you sure you want to continue connecting (yes/no)? no Host key verification failed.
Das sieht so aus, als ob Du für den Host-Key doch noch nicht "yes" eingetippt hast. Oder Du hast es für den Rechner_namen_ gemacht und probierst es jetzt mit der IP. Jedenfalls: Bis hierhin hatte SSH noch gar keine Gelegenheit, den Key oder ein Passwort zwecks Login zu verwenden. Es gab daher auch keinen Fehler (außer dass Du "no" eingetippt hast ;-) Wenn es nach Akzeptieren des Host-Keys immer noch nicht geht, lösche mal auf beiden Rechnern ~/.ssh (naja, known_hosts kannst Du behalten) und folge anschließend der Anleitung in der FAQ: 10.3. Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? http://suse-linux-faq.koehntopp.de/q/q-ssh-keygen.html Gruß Christian Boltz --
Dooooooooooooooooooch!!! ;-) N! cb@tux:~> echo 'N!' | php Parse error: parse error, unexpected '>' in - on line 1 [> Ratti und Christian Boltz in fontlinge-devel]
Christian Boltz schrieb:
Wenn es nach Akzeptieren des Host-Keys immer noch nicht geht, lösche mal auf beiden Rechnern ~/.ssh (naja, known_hosts kannst Du behalten) und folge anschließend der Anleitung in der FAQ:
10.3. Wie erstellt man einen SSH-Key? Wie kommt der Key auf den Zielrechner? http://suse-linux-faq.koehntopp.de/q/q-ssh-keygen.html
habe ich gemacht: ralfk@linux:~> ssh-keygen -t dsa -b 2048 Generating public/private dsa key pair. Enter file in which to save the key (/home/ralf/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/ralf/.ssh/id_dsa. Your public key has been saved in /home/ralf/.ssh/id_dsa.pub. ralfk@sweaty:~/.ssh> ll -rw-r--r-- 1 ralfk users 1113 2005-10-22 08:20 authorized_keys Beim Einloggen wird aber immer noch nach dem Passwort des Users Ralfk gefragt und nicht wie erwartet die Passphrase des privaten Schlüssels. ralfk@linux:~> ssh -vvvv sweaty OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to sweaty [192.168.0.6] port 22. debug1: Connection established. debug1: identity file /home/ralf/.ssh/identity type -1 debug1: identity file /home/ralf/.ssh/id_rsa type -1 debug3: Not a RSA1 key file /home/ralf/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/ralf/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8p1 debug1: match: OpenSSH_3.8p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.8p1 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 125/256 debug2: bits set: 525/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /home/ralf/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'sweaty' is known and matches the RSA host key. debug1: Found key in /home/ralf/.ssh/known_hosts:1 debug2: bits set: 494/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/ralf/.ssh/identity ((nil)) debug2: key: /home/ralf/.ssh/id_rsa ((nil)) debug2: key: /home/ralf/.ssh/id_dsa (0x808a538) debug1: Authentications that can continue: publickey,keyboard-interactive debug3: start over, passed a different list publickey,keyboard-interactive debug3: preferred publickey,keyboard-interactive,password 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/ralf/.ssh/identity debug3: no such identity: /home/ralf/.ssh/identity debug1: Trying private key: /home/ralf/.ssh/id_rsa debug3: no such identity: /home/ralf/.ssh/id_rsa debug1: Offering public key: /home/ralf/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,keyboard-interactive debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1 Password: debug3: packet_send2: adding 32 (len 21 padlen 11 extra_pad 64) debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug3: packet_send2: adding 48 (len 10 padlen 6 extra_pad 64) debug1: Authentication succeeded (keyboard-interactive). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: ssh_session2_setup: id 0 debug2: channel 0: request pty-req debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 0 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 0 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell debug2: fd 3 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Sat Oct 22 08:22:09 2005 from linux Gruß Ralf
Moin,
On Sat, 22 Oct 2005 08:45:08 +0200
Ralf Kleemann
ralfk@sweaty:~/.ssh> ll -rw-r--r-- 1 ralfk users 1113 2005-10-22 08:20 authorized_keys
Beim Einloggen wird aber immer noch nach dem Passwort des Users Ralfk gefragt und nicht wie erwartet die Passphrase des privaten Schlüssels.
ralfk@linux:~> ssh -vvvv sweaty OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004 [...] debug1: identity file /home/ralf/.ssh/id_dsa type 2
Der Client will's also benutzen.
debug1: Host 'sweaty' is known and matches the RSA host key.
Und du hast auch den Host-Key mittlerweile clientseitig akzeptiert.
[...] debug1: Offering public key: /home/ralf/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,keyboard-interactive debug2: we did not send a packet, disable method
Huh? Also hier lehnt entweder der Server oder der Client etwas ab, daraus werde ich nicht ganz schlau... Ich meine, "we did not send a packet" ist ja nun gemessen an dem, was zwei Zeilen 'drüber steht, auch nicht ganz wahr...
debug3: authmethod_lookup keyboard-interactive [...]
...und dass du dann demnächst nach dem Passwort gefragt wirst, ist kein Wunder. Ein paar Ansätze, weiterzusuchen: - sshd.conf (serverseitig, versteht sich) mal genau angucken. - Logging beim Server hochziehen und sshd-Logfiles im Auge behalten. _ganz_ vielleicht erwartet dein sshd die "authorized_keys" auch noch als "authorized_keys2" - aber das glaube ich eher nicht, das war noch vor der SuSE 9.1... Achso, ja, fast vergessen, hihi: Den Fingerprint des Server-Keys hast du aber verglichen, oder (hehehe, wer macht das schon...)? Vielleicht bist du ja auch mittendrin in einer Man-in-the-middle-Attacke. Gruß, -hwh
participants (5)
-
Christian Boltz -
Hans-Werner Hilse -
Markus Heidinger -
Peter Wiersig -
Ralf Kleemann