Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen. local host: ssh: SSH Secure Shell 3.0.1 (non-commercial version) on sparc-sun-solaris2.7 remote host: OpenSSH_3.9p1, OpenSSL 0.9.7b 10 Apr 2003 (SuSE 9.0) Was ich gemacht habe: user1@local host> ssh-keygen -t dsa user1@local host> scp id_dsa.pub user2@remote_host:/home/user/.ssh user2@remote host> cd /home/user/.ssh user2@remote host> cat id_dsa.pub >> authotized_keys2 user2@remote host> rm id_dsa.pub user1@local host> ssh user2@remote_host --> es kommt immer noch Passwortabfrage Ich habe es auch schon mit authorized_keys statt authorized_keys2 probiert. Habe ich da was komplett falsch gemacht oder was kann die Ursache sein? Bin fuer jeden Tipp dankbar. Gruss, ulrich Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller@mpia.de
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 25 October 2004 15:26, Ulrich Hiller wrote:
ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen. local host: ssh: SSH Secure Shell 3.0.1 (non-commercial version) on sparc-sun-solaris2.7 remote host: OpenSSH_3.9p1, OpenSSL 0.9.7b 10 Apr 2003 (SuSE 9.0)
Was ich gemacht habe: user1@local host> ssh-keygen -t dsa user1@local host> scp id_dsa.pub user2@remote_host:/home/user/.ssh
user2@remote host> cd /home/user/.ssh user2@remote host> cat id_dsa.pub >> authotized_keys2
authotized_keys2: sollte es nicht authorized_keys lauten? (s/ot/or/)
user2@remote host> rm id_dsa.pub
user1@local host> ssh user2@remote_host --> es kommt immer noch Passwortabfrage
Ich habe es auch schon mit authorized_keys statt authorized_keys2 probiert. Habe ich da was komplett falsch gemacht oder was kann die Ursache sein? Bin fuer jeden Tipp dankbar.
mit ssh -v müsste sowas ähnliches erscheinen: ... debug1: Next authentication method: publickey debug1: Offering public key: /home/r2/.ssh/id_dsa debug1: Server accepts key: pkalg ssh-dss blen 818 debug1: Authentication succeeded (publickey). ... Du kannst auch den Server mal mit "sshd -ddd -p 8055" oder so starten. Dann ist er im Debugging Mode und schwätzt recht viel auf stderr. Die Geschätzigkeit regelst Du mit der Anzahl der d's. In diesem Mode bleibt der Server im Vordergrund, Du siehst also den stderr auf dem Bildschirm. Außerdem nimmt er nur eine Verbindung auf Port 8055 an, bearbeitet diese und beendet sich danach. Mit "ssh -vvv -p 8055 remote_host" nimmst Du dann Verbindung mit dem eben gestarteten Server auf (3 v ist recht geschwätzig).
Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg
Grüße auf den Berg aus Gaiberg, Torsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBfQX9wicyCTir8T4RAp64AJ9SJaBqJ7EzxT2NtOsczYO945MhXgCfdJ9u QCYJKuAkCWrvUWFUPGelzJ0= =Xv3I -----END PGP SIGNATURE-----
Hi! Ulrich Hiller wrote:
Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen.
dasselbe problem habe ich hier seit der 9.1. Mit der 9.0 klappte es in identischer konfiguration noch problemlos, seit die server auf 9.1 laufen geht es nicht. Im log steht sogar das er public key benutzt, aber dann kommt doch eine passwortabfrage. Anscheinen kann er nichts damit anfangen. leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest? Ciao T
Hallo! schaue doch mal nach was bei dir in /etc/ssh/ssh_config als default steht. So wie es aussieht ist das (per publickey) per default nicht aktiviert. Wenn ich es richtig sehe musst du (for protocol version 2) noch den folgenden Eintrag setzen: PubkeyAuthentication yes [laut man ssh_config: PubkeyAuthentication Specifies whether to try public key authentication. The argument to this keyword must be ``yes'' or ``no''. The default is ``yes''. This option applies to protocol version 2 only.] Gruß, Danny Am Montag, 25. Oktober 2004 17:12 schrieb Dr. Thorsten Brandau:
Hi!
Ulrich Hiller wrote:
Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen.
dasselbe problem habe ich hier seit der 9.1. Mit der 9.0 klappte es in identischer konfiguration noch problemlos, seit die server auf 9.1 laufen geht es nicht. Im log steht sogar das er public key benutzt, aber dann kommt doch eine passwortabfrage. Anscheinen kann er nichts damit anfangen.
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest?
Ciao
T
Am Montag, 25. Oktober 2004 17:56 schrieb Danny Kukawka:
Hallo!
schaue doch mal nach was bei dir in /etc/ssh/ssh_config als default steht. So wie es aussieht ist das (per publickey) per default nicht aktiviert. nach "man" schon per default aktiviert (überlesen, sorry), die Frage ist nur ob auch bei SUSE (habe nicht nachgeschaut)
Wenn ich es richtig sehe musst du (for protocol version 2) noch den folgenden Eintrag setzen:
PubkeyAuthentication yes
[laut man ssh_config:
PubkeyAuthentication Specifies whether to try public key authentication. The argument to this keyword must be ``yes'' or ``no''. The default is ``yes''. This option applies to protocol version 2 only.]
Gruß,
Danny
Am Montag, 25. Oktober 2004 17:12 schrieb Dr. Thorsten Brandau:
Hi!
Ulrich Hiller wrote:
Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen.
dasselbe problem habe ich hier seit der 9.1. Mit der 9.0 klappte es in identischer konfiguration noch problemlos, seit die server auf 9.1 laufen geht es nicht. Im log steht sogar das er public key benutzt, aber dann kommt doch eine passwortabfrage. Anscheinen kann er nichts damit anfangen.
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest?
Ciao
T
Hi! Danny Kukawka wrote:
schaue doch mal nach was bei dir in /etc/ssh/ssh_config als default steht. So wie es aussieht ist das (per publickey) per default nicht aktiviert.
Nein, das ist per default aktiviert und ich habe es zusätzlich per Hand aktiviert (PubkeyAuthentication yes). Geht aber trotzdem nicht. Noch ne idee? ciao T
Hallo On Monday 25 October 2004 17:12, Dr. Thorsten Brandau wrote:
dasselbe problem habe ich hier seit der 9.1. Mit der 9.0 klappte es in identischer konfiguration noch problemlos, seit die server auf 9.1 laufen geht es nicht. Im log steht sogar das er public key benutzt, aber dann kommt doch eine passwortabfrage. Anscheinen kann er nichts damit anfangen.
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest? Es ist gar kein Problem aufgetaucht. :-) Für den client sollte sich eigentlich nichts ändern. Per Voreinstellung ist auch immernoch ssh Version 1 möglich. Schick mal mehr Details (Ausgabe von ssh -vvv oder besagtes Log). Ist so etwas schwierig das nachzuvollziehen.
mfg Axel
Hi Axel, Axel Heinrici wrote:
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest?
Es ist gar kein Problem aufgetaucht. :-) Für den client sollte sich eigentlich nichts ändern. Per Voreinstellung ist auch immernoch ssh Version 1 möglich. Schick mal mehr Details (Ausgabe von ssh -vvv oder besagtes Log). Ist so etwas schwierig das nachzuvollziehen.
Die identische konfiguration hat problemlos funktioniert solange der server <=9.0 war (und tuts auch immer noch). hier das log: Bitte schoen: OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc] debug2: ssh_connect: needpriv 0 debug1: Connecting to zoidberg [192.168.1.40] port 22. debug1: Connection established. debug1: identity file /home/crash/.ssh/identity type -1 debug3: Not a RSA1 key file /home/crash/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' 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 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 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/crash/.ssh/id_rsa type 1 debug3: Not a RSA1 key file /home/crash/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' 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 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/crash/.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.7.1p2 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 debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc 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 sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 132/256 debug2: bits set: 1020/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/crash/.ssh/known_hosts debug3: check_host_in_hostfile: match line 9 debug1: Host 'zoidberg' is known and matches the RSA host key. debug1: Found key in /home/crash/.ssh/known_hosts:9 debug2: bits set: 996/2048 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/crash/.ssh/identity ((nil)) debug2: key: /home/crash/.ssh/id_rsa (0x808c0f8) debug2: key: /home/crash/.ssh/id_dsa (0x808c110) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,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/crash/.ssh/identity debug3: no such identity: /home/crash/.ssh/identity debug1: Offering public key: /home/crash/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /home/crash/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,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
Am Mittwoch, 27. Oktober 2004 10:35 schrieb Dr. Thorsten Brandau:
Hi Axel,
Axel Heinrici wrote:
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest?
Es ist gar kein Problem aufgetaucht. :-) Für den client sollte sich eigentlich nichts ändern. Per Voreinstellung ist auch immernoch ssh Version 1 möglich. Schick mal mehr Details (Ausgabe von ssh -vvv oder besagtes Log). Ist so etwas schwierig das nachzuvollziehen.
Die identische konfiguration hat problemlos funktioniert solange der server <=9.0 war (und tuts auch immer noch).
hier das log: Bitte schoen:
debug1: identity file /home/crash/.ssh/identity type -1 debug3: Not a RSA1 key file /home/crash/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace
Auf den ersten Blick sieht das aus, also wolle ssh dort eigendlich den public Key überprüfen (und erwartet wohl eigendlich den Beginn vom PublicKey, also "ssh-rsa" oder "ssh-dsa"). Sieht aber so aus, als ob das File mit den PrivateKey geöffnet wurde. Hat da jemand die Dateien vertauscht? Irgendwie öffnet der ja nach Log auch: "id_rsa." statt "id_rsa.pub" oder was auch immer er öffnen müsste. Gruß, Danny
Hi zusammen, ich habe mich hier in der Firma auch etwas mit dem Thema ssh auseinandergesetzt und dabei auch das Problem gehabt, dass IMMER das Password abgefragt wurde, ganz gleich auf welchem Host ich die Keys erzeugt hatte mit/ohne passphrase. Wir habe hier Solaris 7,8,9, Linux SuSE/RedHat mit unterschiedlichen ssh versionen. Letztendlich hat es ab dem Zeitpunkt funktioniert, als ich das File .ssh/known_hosts gelöscht hatte. Irgendwann ist da mal wohl Mist reingekommen. Nun gibt's das File wieder und ssh fragt mich nur noch nach der Passphrase. Weiterhin müssen die Key-Files in .ssh alle die Permission 600 haben. Wenn beispielsweise .ssh/authorized_keys 644 hat, fragt die ssh auch immer nach dem Password. Aber da schaut dann der Debug-Output etwas anders aus. Ich hoffe ich konnte helfen. Grüsse Werner
Hi! Danny Kukawka wrote:
Auf den ersten Blick sieht das aus, also wolle ssh dort eigendlich den public Key überprüfen (und erwartet wohl eigendlich den Beginn vom PublicKey, also "ssh-rsa" oder "ssh-dsa"). Sieht aber so aus, als ob das File mit den PrivateKey geöffnet wurde.
ja, es muss ja auch der private key auf dem client geoeffnet werden um zu pruefen ob er zu dem public key des servers passt. insofern ist das schon korrekt...
Hat da jemand die Dateien vertauscht? Irgendwie öffnet der ja nach Log auch: "id_rsa." statt "id_rsa.pub" oder was auch immer er öffnen müsste.
hatte ich vor einiger zeit probeweise mal probiert, ging aber auch nicht. ratlos, T
Am Mittwoch, 27. Oktober 2004 13:39 schrieb Dr. Thorsten Brandau:
Hi!
Danny Kukawka wrote:
Auf den ersten Blick sieht das aus, also wolle ssh dort eigendlich den public Key überprüfen (und erwartet wohl eigendlich den Beginn vom PublicKey, also "ssh-rsa" oder "ssh-dsa"). Sieht aber so aus, als ob das File mit den PrivateKey geöffnet wurde.
ja, es muss ja auch der private key auf dem client geoeffnet werden um zu pruefen ob er zu dem public key des servers passt. insofern ist das schon korrekt...
Schon klar! Aber er versucht ja in den folgenden Zeilen einen flag für den Typ des ssh-Keys zu finden ... debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace sieht wie gesagt aus, als ob er da eigendlich den Flag "ssh-rsa" bzw "ssh-dss" und das nachfolgende Leerzeichen erwartet, aber nicht findet. Lösche doch einfach mal auf beiden Rechner alles in .ssh Dann einfach neue Keys generieren (ohne Passwort ....! sonst wird natürlich nach einem Password gefragt, wenn ich nicht irre) und den PublicKey (des Rechners von dem du dich einloggen willst) entsprechend in die authorized_keys des Rechners kopieren, auf den du dich einloggen willst. Dann funzt es vielleicht! Viel Glück ...
Hat da jemand die Dateien vertauscht? Irgendwie öffnet der ja nach Log auch: "id_rsa." statt "id_rsa.pub" oder was auch immer er öffnen müsste.
hatte ich vor einiger zeit probeweise mal probiert, ging aber auch nicht.
ratlos,
T
Hallo, Am Mittwoch, 27. Oktober 2004 10:35 schrieb Dr. Thorsten Brandau:
Hi Axel,
Axel Heinrici wrote:
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest?
Ich hab nach einigem Hin und her hier einige Rechner mit 9.1 und 9.0 bei denen eine Anmeldung via ssh in allen Richtungen geht. Ich hab mir ganz schön einen abgebrochen um genau diese Möglichkeit ein passwort einzugeben abzuschalten (es darf sich nur anmelden, wer auch den korrekten Schlüssel hat!)
Es ist gar kein Problem aufgetaucht. :-) Für den client sollte sich eigentlich nichts ändern. Per Voreinstellung ist auch immernoch ssh Version 1 möglich. Schick mal mehr Details (Ausgabe von ssh -vvv oder besagtes Log). Ist so etwas schwierig das nachzuvollziehen.
Die identische konfiguration hat problemlos funktioniert solange der server <=9.0 war (und tuts auch immer noch).
hier das log: clientseite!? Bitte schoen:
OpenSSH_3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7b 10 Apr 2003 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug3: cipher ok: aes128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: cipher ok: 3des-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: cipher ok: blowfish-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: cipher ok: cast128-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: cipher ok: arcfour [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: cipher ok: aes192-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: cipher ok: aes256-cbc [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug3: ciphers ok: [aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes2 56-cbc] debug2: ssh_connect: needpriv 0 debug1: Connecting to zoidberg [192.168.1.40] port 22. das ist der 'remote' rechner. Gibts da auch ein log??? debug1: Connection established. debug1: identity file /home/crash/.ssh/identity type -1 debug3: Not a RSA1 key file /home/crash/.ssh/id_rsa. Hier wird auf ssh v1 geprüft! debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype ... wg. v1 debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /home/crash/.ssh/id_dsa type 2
ab hier ssh v2
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 ... debug3: check_host_in_hostfile: filename /home/crash/.ssh/known_hosts debug3: check_host_in_hostfile: match line 9 debug1: Host 'zoidberg' is known and matches the RSA host key. debug1: Found key in /home/crash/.ssh/known_hosts:9
da wurde etwas gültiges gefunden
debug2: bits set: 996/2048 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/crash/.ssh/identity ((nil)) debug2: key: /home/crash/.ssh/id_rsa (0x808c0f8) debug2: key: /home/crash/.ssh/id_dsa (0x808c110) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,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/crash/.ssh/identity debug3: no such identity: /home/crash/.ssh/identity debug1: Offering public key: /home/crash/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /home/crash/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive ab hier ist was faul! der entsprechende Ausschnitt bei mir (ssh -vvv user@rechner)
debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: /home/rma/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 149 da würde ein log von der remoten Rechner (möglicherweise!) weiterhelfen! irgendwas stimmt den schlüsseln nicht, da der versendete offensichtlich nicht akzeptiert wird !
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
hier wird dann nach dem PW gefragt :-(
debug2: we sent a keyboard-interactive packet, wait for reply debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 1
Viel Glück -- MfG Rolf Masfelder EMail: rolf.masfelder@nector.de
Hi On Wednesday 27 October 2004 10:35, Dr. Thorsten Brandau wrote:
Hi Axel,
Axel Heinrici wrote:
leider konnte ich das problem ebenfalls noch nicht loesen. Hat jemand bisher mit der 9.1 das problem geloest?
Es ist gar kein Problem aufgetaucht. :-) Für den client sollte sich eigentlich nichts ändern. Per Voreinstellung ist auch immernoch ssh Version 1 möglich. Schick mal mehr Details (Ausgabe von ssh -vvv oder besagtes Log). Ist so etwas schwierig das nachzuvollziehen.
Die identische konfiguration hat problemlos funktioniert solange der server <=9.0 war (und tuts auch immer noch). Ich habe auch auf 9.1 erneuert und es geht alles wie vorher.
hier das log: Bitte schoen:
....
debug1: Trying private key: /home/crash/.ssh/identity debug3: no such identity: /home/crash/.ssh/identity debug1: Offering public key: /home/crash/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Hmmpf. Hier schient der server tatsächlich nirgendwie nicht mehr zu antworten. debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Offering public key: /home/crash/.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply Schon wieder das gleiche. Hier sollte es definitiv anders weitergehen. debug1: Authentications that can continue: ....
Bei mir geht es zwar anders weiter als in dem Beispiel von Rolf. Aber ich stimme ihm zu, dass hier wohl nur noch das server-log hilft (am einfachsten eigenen server mit "sshd -ddd -p <port>" starten). Bei mir kommt dann (hab nur dsa) anstelle des "Authentication that can..." ein: debug1: input_userauth_pk_ok: ..... debug2: input_userauth_pk_ok: fp ..... debug3: sign_and_send_pubkey debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type <unknown> Enter passphrase for key '/home/axel/.ssh/id_dsa': debug1: read PEM private key done: type DSA debug1: ssh-userauth2 successful: method publickey mfg Axel
Hi On Monday 25 October 2004 15:26, Ulrich Hiller wrote:
Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen. local host: ssh: SSH Secure Shell 3.0.1 (non-commercial version) on sparc-sun-solaris2.7 remote host: OpenSSH_3.9p1, OpenSSL 0.9.7b 10 Apr 2003 (SuSE 9.0) Du willst dich also vom solaris-Rechner per ssh auf dem SuSE-Rechner bei OpenSSH einloggen. Oberachtung mit den Dateiformaten und Dateinamen.
Was ich gemacht habe: user1@local host> ssh-keygen -t dsa user1@local host> scp id_dsa.pub user2@remote_host:/home/user/.ssh Bei OpenSSH ein korrektes Vorgehen. Ob das beim kommerziellen ssh richtig ist glaube ich allerdings kaum. Ich habe mal was von einer ~/ssh2/identification Datei gelesen, die die Dateinamen der eigentlichen keyfiles enthält.
user2@remote host> cd /home/user/.ssh user2@remote host> cat id_dsa.pub >> authotized_keys2 user2@remote host> rm id_dsa.pub
user1@local host> ssh user2@remote_host --> es kommt immer noch Passwortabfrage
Ich habe es auch schon mit authorized_keys statt authorized_keys2 probiert. Habe ich da was komplett falsch gemacht oder was kann die Ursache sein? Bin fuer jeden Tipp dankbar. Tips zu diversen debug-Optionen kamen ja schon. Bevor du dir jetzt aber den ganzen Abend romanartige Debugausgaben reinziehst, würde ich mir sicherheitshalber nochmal die manpage des kommerziellen ssh geben. Ob das Format, in dem die keys abgespeichert sind überhaupt kompatibel ist, ist unter Umständen auch noch mal einen Check wert. Das Drama gab es mal bei putty. Und prüfe ob nicht schlimmstenfalls noch ein OpenSSH drauf ist und beispielsweise ssh-keygen zu OpenSSH und ssh-keygen2 zu ssh gehört o.ä.. Am einfachsten ist es vermutlich, wenn du auf der solaris-Maschine auch OpenSSH benutzt.
mfg Axel
Ulrich Hiller schrieb:
Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen. local host: ssh: SSH Secure Shell 3.0.1 (non-commercial version) on sparc-sun-solaris2.7 remote host: OpenSSH_3.9p1, OpenSSL 0.9.7b 10 Apr 2003 (SuSE 9.0)
Was ich gemacht habe: user1@local host> ssh-keygen -t dsa user1@local host> scp id_dsa.pub user2@remote_host:/home/user/.ssh
user2@remote host> cd /home/user/.ssh user2@remote host> cat id_dsa.pub >> authotized_keys2 user2@remote host> rm id_dsa.pub
user1@local host> ssh user2@remote_host --> es kommt immer noch Passwortabfrage
Ich habe es auch schon mit authorized_keys statt authorized_keys2 probiert. Habe ich da was komplett falsch gemacht oder was kann die Ursache sein? Bin fuer jeden Tipp dankbar. Gruss, ulrich
Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller@mpia.de
Ich glaube es liegt einfach daran das die Identfikation per Passwort explizit abgeschaltet werden muss (IMHO) , auch wenn ihr euch per PublicKey anmeldet.
Am Montag 25 Oktober 2004 17:52 schrieb Fabian Franzen: [...]
Ich glaube es liegt einfach daran das die Identfikation per Passwort explizit abgeschaltet werden muss (IMHO) , auch wenn ihr euch per PublicKey anmeldet.
Es geht beides - hab' ich nämlich so in Gebrauch. Wenn der private Key nämlich nicht gefunden wird oder auf der Maschine nicht vorhanden ist, von der aus man sich einloggen will, wird nach dem Passwort gefragt. Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## OpenSource-Werkstatt -- http://www.eschkitai.de/
Hallo Fabian, hallo Leute, Am Montag, 25. Oktober 2004 17:52 schrieb Fabian Franzen:
Ulrich Hiller schrieb: [SSH fragt nach Passwort, obwohl Key verfügbar] Ich glaube es liegt einfach daran das die Identfikation per Passwort explizit abgeschaltet werden muss (IMHO) , auch wenn ihr euch per PublicKey anmeldet.
Nö, das kann es eigentlich nicht sein. Ich verwende meinen SSH-Key auch an ein paar Servern, auf denen auch der Login mit Passwort erlaubt ist. Und trotzdem komme ich mit dem Key passwortlos rein (ssh-agent und ssh-add vorausgesetzt). Es ist allerdings möglich, dass der Server einen Key und *zusätzlich* das Passwort braucht. Ulrich, zeig mal die Konfiguration des sshd auf dem Server [1], vielleicht kommen wir damit weiter. Gruß Christian Boltz [1] ohne Kommentare und Leerzeilen, also per grep "^ *[^#]" datei -- Wenn der IE ein Browser ist, dann produziert Frontpage auch HTML ;-)) [Heinz W. Pahlke in suse-linux]
Christian Boltz schrieb:
Hallo Fabian, hallo Leute,
Am Montag, 25. Oktober 2004 17:52 schrieb Fabian Franzen:
Ulrich Hiller schrieb:
[SSH fragt nach Passwort, obwohl Key verfügbar]
Ich glaube es liegt einfach daran das die Identfikation per Passwort explizit abgeschaltet werden muss (IMHO) , auch wenn ihr euch per PublicKey anmeldet.
Nö, das kann es eigentlich nicht sein.
Ich verwende meinen SSH-Key auch an ein paar Servern, auf denen auch der Login mit Passwort erlaubt ist. Und trotzdem komme ich mit dem Key passwortlos rein (ssh-agent und ssh-add vorausgesetzt).
Es ist allerdings möglich, dass der Server einen Key und *zusätzlich* das Passwort braucht.
Ulrich, zeig mal die Konfiguration des sshd auf dem Server [1], vielleicht kommen wir damit weiter.
Gruß
Christian Boltz
[1] ohne Kommentare und Leerzeilen, also per grep "^ *[^#]" datei
Kann es nicht sein das bei den verschiedenen Versionen das einmal standardmäßig an ist und bei anderen standardmäßig aus?!? Fabian Franzen
Am Montag, 25. Oktober 2004 15:26 schrieb Ulrich Hiller:
Hallo, ich habe ein Problem, ssh-login ohne Passwort-Abfrage zu ermoeglichen. local host: ssh: SSH Secure Shell 3.0.1 (non-commercial version) on sparc-sun-solaris2.7 remote host: OpenSSH_3.9p1, OpenSSL 0.9.7b 10 Apr 2003 (SuSE 9.0)
Was ich gemacht habe: user1@local host> ssh-keygen -t dsa user1@local host> scp id_dsa.pub user2@remote_host:/home/user/.ssh
user2@remote host> cd /home/user/.ssh user2@remote host> cat id_dsa.pub >> authotized_keys2
unter der 9.2 funzt es (out of the box!) wenn du die Datei "authorized_keys" und nicht "authotized_keys2" nennst ;-)
user2@remote host> rm id_dsa.pub
user1@local host> ssh user2@remote_host --> es kommt immer noch Passwortabfrage
Ich habe es auch schon mit authorized_keys statt authorized_keys2 probiert. Habe ich da was komplett falsch gemacht oder was kann die Ursache sein? Bin fuer jeden Tipp dankbar. Gruss, ulrich
Ulrich Hiller Max-Planck-Institut fuer Astronomie Koenigstuhl 17 69117 Heidelberg Germany phone +49 6221 528238 fax +49 6221 528246 email hiller@mpia.de
participants (11)
-
Axel Heinrici -
Christian Boltz -
Danny Kukawka -
Dr. Thorsten Brandau -
Fabian Franzen -
Helga Fischer -
Michael Schachtebeck -
Rolf Masfelder -
Torsten Förtsch -
Ulrich Hiller -
Werner Franke