Verzweiflung: ssh ohne Passwort will nicht
Hallo Leute, hab versucht ssh ohne Passwort einzurichten um von einem Rechner aus einen anderen runterzufahren. Funktioniert einfach nicht, owohl ich einen Thread der kürzlche hierdurchging, diverse gegoogelten Anleitungen und ein gebundens Buch zu Rate gezogen habe. Ich werde trotzdem jedesmal nach der Passphrase gefragt :-(. ___________________________________________________________ jupiter:~ # ssh -v -l remote asterix OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f 5815: debug1: Reading configuration data /etc/ssh/ssh_config 5815: debug1: Applying options for * 5815: debug1: Rhosts Authentication disabled, originating port will not be trusted. 5815: debug1: ssh_connect: needpriv 0 5815: debug1: Connecting to asterix [192.168.0.98] port 22. 5815: debug1: Connection established. 5815: debug1: identity file /root/.ssh/identity type -1 5815: debug1: identity file /root/.ssh/id_rsa type -1 5815: debug1: identity file /root/.ssh/id_dsa type 2 5815: debug1: Remote protocol version 1.99, remote software version OpenSSH_3.4p1 5815: debug1: match: OpenSSH_3.4p1 pat OpenSSH* 5815: Enabling compatibility mode for protocol 2.0 5815: debug1: Local version string SSH-2.0-OpenSSH_3.4p1 5815: debug1: SSH2_MSG_KEXINIT sent 5815: debug1: SSH2_MSG_KEXINIT received 5815: debug1: kex: server->client aes128-cbc hmac-md5 none 5815: debug1: kex: client->server aes128-cbc hmac-md5 none 5815: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent 5815: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 5815: debug1: dh_gen_key: priv key bits set: 127/256 5815: debug1: bits set: 1638/3191 5815: debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 5815: debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 5815: debug1: Host 'asterix' is known and matches the RSA host key. 5815: debug1: Found key in /root/.ssh/known_hosts:1 5815: debug1: bits set: 1623/3191 5815: debug1: ssh_rsa_verify: signature correct 5815: debug1: kex_derive_keys 5815: debug1: newkeys: mode 1 5815: debug1: SSH2_MSG_NEWKEYS sent 5815: debug1: waiting for SSH2_MSG_NEWKEYS 5815: debug1: newkeys: mode 0 5815: debug1: SSH2_MSG_NEWKEYS received 5815: debug1: done: ssh_kex2. 5815: debug1: send SSH2_MSG_SERVICE_REQUEST 5815: debug1: service_accept: ssh-userauth 5815: debug1: got SSH2_MSG_SERVICE_ACCEPT 5815: debug1: authentications that can continue: external-keyx,gssapi,publickey,password 5815: debug1: next auth method to try is publickey 5815: debug1: try privkey: /root/.ssh/identity 5815: debug1: try privkey: /root/.ssh/id_rsa 5815: debug1: try pubkey: /root/.ssh/id_dsa 5815: debug1: input_userauth_pk_ok: pkalg ssh-dss blen 434 lastkey 0x809a268 hint 2 5815: debug1: PEM_read_PrivateKey failed 5815: debug1: read PEM private key done: type <unknown> Enter passphrase for key '/root/.ssh/id_dsa': _______________________________________________________________ Ich habe: auf Rechner A ein Key-Paar erzeugt, den öffentlichen auf Rechner B kopiert und an die Datei .ssh/authorized_keys(2) angehängt, die Rechte aller Dateien in ~/.ssh gecheckt, ssh-agent läuft,...was mach ich falsch? Gruss Michael
Hallo Michael, Am Sonntag Oktober 26 2003 12:22 schrieb Michael Karges:
hab versucht ssh ohne Passwort einzurichten um von einem Rechner aus einen anderen runterzufahren. Funktioniert einfach nicht, owohl ich einen Thread der kürzlche hierdurchging, diverse gegoogelten Anleitungen und ein gebundens Buch zu Rate gezogen habe. Ich werde trotzdem jedesmal nach der Passphrase gefragt :-(.
Damit habe ich auch gekämpft - ich war so eigensinnig, meinen PrivateKey anders zu benennen. Ich muß also immer ssh -i Ort-des-Private-Keys Host angeben, damit das mit dem Schlüssel auch wirklich funktioniert (Meine Einträge in die .ssh-config funktionieren leider nicht).
___________________________________________________________
5815: debug1: identity file /root/.ssh/id_dsa type 2
Du hast einen dsa-Schlüssel erzeugt, der das Openssh-Protokoll 2 verwendet? Hast Du den Standardnamen genommen und den Standardaufbewahrungsort? [...]
5815: debug1: PEM_read_PrivateKey failed 5815: debug1: read PEM private key done: type <unknown>
Hier geht's schief. Was für einen Schlüssel hast Du denn erzeugt? Wie sah Dein ssh-keygen Befehl aus?
Enter passphrase for key '/root/.ssh/id_dsa':
Wenn ssh mit Deinen Schlüsseln nichts anfangen kann, fragst nach der Passphrase.
Ich habe: auf Rechner A ein Key-Paar erzeugt, den öffentlichen auf Rechner B kopiert und an die Datei .ssh/authorized_keys(2)
Heißt das wirklich so? Bei mir heißt das nur authorized_keys.
angehängt, die Rechte aller Dateien in ~/.ssh gecheckt, ssh-agent läuft,...was mach ich falsch?
Hast Du Deine .ssh-config auch bearbeitet? Helga *auch ein wenig ratlos* -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Servus Helga, Am Sonntag, 26. Oktober 2003 14:33 schrieb Helga Fischer:
Hallo Michael,
Am Sonntag Oktober 26 2003 12:22 schrieb Michael Karges:
[snip]
5815: debug1: identity file /root/.ssh/id_dsa type 2
Du hast einen dsa-Schlüssel erzeugt, der das Openssh-Protokoll 2 verwendet? Hast Du den Standardnamen genommen und den Standardaufbewahrungsort?
Protokoll 2, alles auf Standard gelassen.
[...]
5815: debug1: PEM_read_PrivateKey failed 5815: debug1: read PEM private key done: type <unknown>
Hier geht's schief. Was für einen Schlüssel hast Du denn erzeugt? Wie sah Dein ssh-keygen Befehl aus?
ssh-keygen -t dsa
Enter passphrase for key '/root/.ssh/id_dsa':
Wenn ssh mit Deinen Schlüsseln nichts anfangen kann, fragst nach der Passphrase.
Ich habe: auf Rechner A ein Key-Paar erzeugt, den öffentlichen auf Rechner B kopiert und an die Datei .ssh/authorized_keys(2)
Heißt das wirklich so? Bei mir heißt das nur authorized_keys.
Nein ,aber für Protokoll 2 heisst die Datei angeblich "authorized_keys2". Ändert aber nichts am Problem, auch wenn beide vorhanden sind.
angehängt, die Rechte aller Dateien in ~/.ssh gecheckt, ssh-agent läuft,...was mach ich falsch?
Hast Du Deine .ssh-config auch bearbeitet?
Was konkret is da zu ändern?
Helga *auch ein wenig ratlos*
Gruss Michael
Hi Michael, Am Sonntag Oktober 26 2003 15:04 schrieb Michael Karges:
Am Sonntag, 26. Oktober 2003 14:33 schrieb Helga Fischer:
Am Sonntag Oktober 26 2003 12:22 schrieb Michael Karges:
[snip]
5815: debug1: identity file /root/.ssh/id_dsa type 2
Du hast einen dsa-Schlüssel erzeugt, der das Openssh-Protokoll 2 verwendet? Hast Du den Standardnamen genommen und den Standardaufbewahrungsort?
Protokoll 2, alles auf Standard gelassen.
Hmm... OK, so habe ich das mit meinen ersten Versuchen auch gemacht und sieht ssh vor.
[...]
5815: debug1: PEM_read_PrivateKey failed 5815: debug1: read PEM private key done: type <unknown>
Hier geht's schief. Was für einen Schlüssel hast Du denn erzeugt? Wie sah Dein ssh-keygen Befehl aus?
ssh-keygen -t dsa
OK, so sieht es bei mir auch aus.
Enter passphrase for key '/root/.ssh/id_dsa':
Wenn ssh mit Deinen Schlüsseln nichts anfangen kann, fragst nach der Passphrase.
Ich habe: auf Rechner A ein Key-Paar erzeugt, den öffentlichen auf Rechner B kopiert und an die Datei .ssh/authorized_keys(2)
Heißt das wirklich so? Bei mir heißt das nur authorized_keys.
Nein ,aber für Protokoll 2 heisst die Datei angeblich "authorized_keys2". Ändert aber nichts am Problem, auch wenn beide vorhanden sind.
Ahja, diese Information hatte ich nicht.
angehängt, die Rechte aller Dateien in ~/.ssh gecheckt, ssh-agent läuft,...was mach ich falsch?
Hast Du Deine .ssh-config auch bearbeitet?
Was konkret is da zu ändern?
Im Originalzustand ist alles auskommentiert. Ich habe ein paar Sachen angeschaltet: # IdentityFile ~/.ssh/identity # IdentityFile ~/.ssh/id_rsa # IdentityFile ~/.ssh/id_dsa Hier das passende (was in meinem Fall nicht funktionieren will, warum, habe ich noch nicht heraus gefunden). Und die beiden noch, wobei es besser wäre, nur Protocol 2 zuzulassen. Port 22 Protocol 2,1 Ich lief auch einen ganzen Nachmittag lang in die Frage nach der Passphrase rein, bis es irgendwann funktionierte. Leider kann ich nicht mit dem Finger drauf zeigen, warum es jetzt tut. Allerdings, mir fällt gerade ein, ich habe dieses Schlüsselpaar, das ich zwischen meinen beiden Linuxen zu Hause verwende, _ohne_ Passphrase erzeugt. Ich muß also den PrivateKey anderweitig schützen (Zugriffsrechte, externes Medium). Bei OOo werde ich auf die gleiche Weise authentifiziert, aber der PrivateKey hat hier eine Passphrase - danach werde ich immer noch gefragt. Wenn mir das lästig würde, müßte ich am beginn meiner Sitzung mit dem ssh-agent arbeiten (habe ich noch nicht ausprobiert). Liegt es vielleicht daran? Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Am Sonntag, 26. Oktober 2003 16:03 schrieb Helga Fischer:
Hi Michael,
[snip]
Allerdings, mir fällt gerade ein, ich habe dieses Schlüsselpaar, das ich zwischen meinen beiden Linuxen zu Hause verwende, _ohne_ Passphrase erzeugt. Ich muß also den PrivateKey anderweitig schützen (Zugriffsrechte, externes Medium).
Ja, das wars!!! Ohne Passphrase auf Anhieb, alle anderen Einstellungen als Default.
Bei OOo werde ich auf die gleiche Weise authentifiziert, aber der PrivateKey hat hier eine Passphrase - danach werde ich immer noch gefragt. Wenn mir das lästig würde, müßte ich am beginn meiner Sitzung mit dem ssh-agent arbeiten (habe ich noch nicht ausprobiert).
Liegt es vielleicht daran?
Helga
Herzlichen Dank für den Tipp, hab zwar noch nicht verstanden warum die Passphrase im Weg ist, aber so funktioniert es mal. Gruss Michael
Am Sonntag Oktober 26 2003 16:14 schrieb Michael Karges:
Am Sonntag, 26. Oktober 2003 16:03 schrieb Helga Fischer: [snip]
Allerdings, mir fällt gerade ein, ich habe dieses Schlüsselpaar, das ich zwischen meinen beiden Linuxen zu Hause verwende, _ohne_ Passphrase erzeugt.
Ja, das wars!!! Ohne Passphrase auf Anhieb, alle anderen Einstellungen als Default.
Prima.
Herzlichen Dank für den Tipp, hab zwar noch nicht verstanden warum die Passphrase im Weg ist, aber so funktioniert es mal.
Die Passphrase ist nicht im Weg, es sind zwei verschieden hohe Sicherheitsanforderungen. Man kann das Keypair mit Passphrase erzeugen, muß aber nicht. Wenn Du Letzteres tust, mußt Du wissen, daß Dir mit Entwenden des PrivatKey Ungemach droht. Ist dieser aber durch die Passphrase geschützt, kann der Dieb nichts mit anfangen, außer lange heftig viel rechnen *g*. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Hallo Michael, . . .
Am Sonntag Oktober 26 2003 16:14 schrieb Michael Karges:
Am Sonntag, 26. Oktober 2003 16:03 schrieb Helga Fischer: [snip]
Allerdings, mir fällt gerade ein, ich habe dieses Schlüsselpaar, das ich zwischen meinen beiden Linuxen zu Hause verwende, _ohne_ Passphrase erzeugt.
Ja, das wars!!! Ohne Passphrase auf Anhieb, alle anderen Einstellungen als Default.
Prima.
Herzlichen Dank für den Tipp, hab zwar noch nicht verstanden warum die Passphrase im Weg ist, aber so funktioniert es mal.
Die Passphrase ist nicht im Weg, es sind zwei verschieden hohe Sicherheitsanforderungen. Man kann das Keypair mit Passphrase erzeugen, muß aber nicht.
Wenn Du Letzteres tust, mußt Du wissen, daß Dir mit Entwenden des PrivatKey Ungemach droht. Ist dieser aber durch die Passphrase geschützt, kann der Dieb nichts mit anfangen, außer lange heftig viel rechnen *g*.
Ich halte nicht viel von ohne "passphrase" und ähnlichem. Man kann auch mit passphrase bei der richtigen Konfiguration von ssh ohne Passwortabfrage mit ssh arbeiten. Ich compiliere beispielsweise meine Software auf unterschiedlichsten Plattformen (Linux oder Unix) automatisch mittels eines Skritps. Wichtig bei der ganzen Sache ist, dass man den ssh-agent starten muss, sonst wir immer nach einem Passwort gefragt. Geradezu perfekt wird die ssh-Konfiguration auf folgender URL beschrieben: http://www.lrz-muenchen.de/services/security/ssh/ Wenn Du das genau abarbeitest, sollte es keine Probleme und Unahnemhlichkeiten geben. Gruß Alexander
Michael Karges wrote:
Hallo Leute, hab versucht ssh ohne Passwort einzurichten um von einem Rechner aus einen anderen runterzufahren. Funktioniert einfach nicht, owohl ich einen Thread der kürzlche hierdurchging, diverse gegoogelten Anleitungen und ein gebundens Buch zu Rate gezogen habe. Ich werde trotzdem jedesmal nach der Passphrase gefragt :-(.
Das der nach der Passphrase fragt, ist völlig O.K. Dafür gibt es den ssh-agent, der auch in den neueren Versionen von Suse ohne größere Eingriffe funktioniert. Du mußt nur in Deiner ~/.xsession die Variable "usessh" auf "yes" setzten. Dann wird dieser Agent gestartet, der einmalig der Dialogbox nach der Passphrase fragt (geht also auch aus Shellscripts raus), und sich die dann bis zum ausloggen merkt. Eine andere Sache ist, daß ssh manchmal einfach auch mit gutem Zureden keine Key-Authentifizierung machen will. Z.B. wenn ich von Suse 8.2 auf Redhat 7.2 (beides Standard-Konfiguration) DSA-Authentifizierung machen will, er macht es einfach nicht:(s. Anhang). Also, wenn mir das mal jemand sagen könnte, wie man das hinbekommt, das wäre Klasse! :-) Viele Grüße, Gordon. OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f 3905: debug1: Reading configuration data /etc/ssh/ssh_config 3905: debug1: Applying options for * 3905: debug1: Rhosts Authentication disabled, originating port will not be trusted. 3905: debug1: ssh_connect: needpriv 0 3905: debug1: Connecting to holsten [192.168.43.17] port 22. 3905: debug1: Connection established. 3905: debug1: identity file /home/gordon/.ssh/identity type -1 3905: debug2: key_type_from_name: unknown key type '-----BEGIN' 3905: debug2: key_type_from_name: unknown key type '-----END' 3905: debug1: identity file /home/gordon/.ssh/id_rsa type 1 3905: debug2: key_type_from_name: unknown key type '-----BEGIN' 3905: debug2: key_type_from_name: unknown key type '-----END' 3905: debug1: identity file /home/gordon/.ssh/id_dsa type 2 3905: debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 3905: debug1: match: OpenSSH_2.9p2 pat OpenSSH_2.9p* 3905: debug1: Enabling compatibility mode for protocol 2.0 3905: debug1: Local version string SSH-2.0-OpenSSH_3.5p1 3905: debug1: SSH2_MSG_KEXINIT sent 3905: debug1: SSH2_MSG_KEXINIT received 3905: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 3905: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss 3905: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se 3905: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se 3905: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 3905: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 3905: debug2: kex_parse_kexinit: none,zlib 3905: debug2: kex_parse_kexinit: none,zlib 3905: debug2: kex_parse_kexinit: 3905: debug2: kex_parse_kexinit: 3905: debug2: kex_parse_kexinit: first_kex_follows 0 3905: debug2: kex_parse_kexinit: reserved 0 3905: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 3905: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss 3905: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se 3905: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc@lysator.liu.se 3905: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 3905: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 3905: debug2: kex_parse_kexinit: none,zlib 3905: debug2: kex_parse_kexinit: none,zlib 3905: debug2: kex_parse_kexinit: 3905: debug2: kex_parse_kexinit: 3905: debug2: kex_parse_kexinit: first_kex_follows 0 3905: debug2: kex_parse_kexinit: reserved 0 3905: debug2: mac_init: found hmac-md5 3905: debug1: kex: server->client aes128-cbc hmac-md5 none 3905: debug2: mac_init: found hmac-md5 3905: debug1: kex: client->server aes128-cbc hmac-md5 none 3905: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent 3905: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 3905: debug1: dh_gen_key: priv key bits set: 121/256 3905: debug1: bits set: 1002/2049 3905: debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 3905: debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 3905: debug1: Host 'holsten' is known and matches the RSA host key. 3905: debug1: Found key in /home/gordon/.ssh/known_hosts:2 3905: debug1: bits set: 1041/2049 3905: debug1: ssh_rsa_verify: signature correct 3905: debug1: kex_derive_keys 3905: debug1: newkeys: mode 1 3905: debug1: SSH2_MSG_NEWKEYS sent 3905: debug1: waiting for SSH2_MSG_NEWKEYS 3905: debug1: newkeys: mode 0 3905: debug1: SSH2_MSG_NEWKEYS received 3905: debug1: done: ssh_kex2. 3905: debug1: send SSH2_MSG_SERVICE_REQUEST 3905: debug1: service_accept: ssh-userauth 3905: debug1: got SSH2_MSG_SERVICE_ACCEPT 3905: debug1: authentications that can continue: publickey,password,keyboard-interactive 3905: debug1: next auth method to try is publickey 3905: debug2: userauth_pubkey_agent: no keys at all 3905: debug2: userauth_pubkey_agent: no more keys 3905: debug2: userauth_pubkey_agent: no message sent 3905: debug1: try privkey: /home/gordon/.ssh/identity 3905: debug1: try pubkey: /home/gordon/.ssh/id_rsa 3905: debug2: we sent a publickey packet, wait for reply 3905: debug1: authentications that can continue: publickey,password,keyboard-interactive 3905: debug2: userauth_pubkey_agent: no more keys 3905: debug2: userauth_pubkey_agent: no message sent 3905: debug1: try pubkey: /home/gordon/.ssh/id_dsa 3905: debug2: we sent a publickey packet, wait for reply 3905: debug1: authentications that can continue: publickey,password,keyboard-interactive 3905: debug2: userauth_pubkey_agent: no more keys 3905: debug2: userauth_pubkey_agent: no message sent 3905: debug2: we did not send a packet, disable method 3905: debug1: next auth method to try is keyboard-interactive 3905: debug2: userauth_kbdint 3905: debug2: we sent a keyboard-interactive packet, wait for reply 3905: debug1: authentications that can continue: publickey,password,keyboard-interactive 3905: debug2: we did not send a packet, disable method 3905: debug1: no more auth methods to try 3905: Permission denied (publickey,password,keyboard-interactive). 3905: debug1: Calling cleanup 0x8068d70(0x0)
participants (4)
-
Alexander Beck-Ratzka -
Gordon Cichon -
Helga Fischer -
Michael Karges