Hallo! Ich versuche seit einiger Zeit von meinem Laptop (jens) hin zu meinem Arbeitsplatzrechner (eta) eine ssl-Verbindung ohne Passwort zu erzeugen. Beide Rechner laufen mit Suse 8.2 und besitzen auch das Update auf OpenSSH_3.5p1-68. Zuerst erzeuge ich auf "jens" einen entsprechenden Schlüssel mit ssh-keygen -t dsa Als Datei geben ich "/home/jens/.ssh/jenstoeta" an. Als Passphrase möchte ich zunächst nichts vorgeben (Eine Passphrase mit einer Verwaltung über einen ssh-Agenten möchte ich später erzeugen, ist jedoch jetzt für mein Problem nicht von belang.) und bestätige daher zweimal mit "return". Den erzeugten Publickey "jenstoeta.pub" kopiere ich nach "eta:/home/jens/.ssh/authority_keys2" Anschließend setze ich auf beiden Rechner noch die Rechte wie folgt: chmod 700 /home/jens/.ssh chmod 600 /home/jens/.ssh/* Danach sollte eigentlich alles funktionieren. Übrigens: Meine config-Datei habe ich wie folgt angelegt: Host eta user jens Compression yes Protocol 2 RSAAuthentication yes StrictHostKeyChecking no ForwardAgent yes ForwardX11 yes IdentityFIle jens:/home/jens/.ssh/jenstoeta Kann mir jemand helfen? Besten Dank Jens
Peter Wiersig schrieb:
Jens Ritzert wrote:
"eta:/home/jens/.ssh/authority_keys2"
Sollte ".ssh/authorized_keys" heissen
(Jede SSH-Version, die "..._keys2" verwendet sollte durch eine neuere ausgetauscht werden)
Hallo! Sorry, war ein Schreibfehler von mir! Ich nenne die Datei natürlich ".ssh/authorized_keys" ... die "2" habe ich nur zusätzlich versucht ...... aber ich muss trotz allem immer wieder ein Passwort eingeben. ..... leider. Grüsse, Jens
Jens Ritzert wrote:
...... aber ich muss trotz allem immer wieder ein Passwort eingeben.
Ich debugge Fehler dieser Art immer mit den folgenden Schritten: Auf dem Server: sshd -Ddp 22222 Auf dem Client: ssh -p 22222 user@server Und bewundere dann die Meldungen auf der Server-Seite, die etwas mit den Public-Keys, bzw. den authorized_keys file anmeckert. -- Have fun, Peter
Peter Wiersig schrieb:
Jens Ritzert wrote:
...... aber ich muss trotz allem immer wieder ein Passwort eingeben.
Ich debugge Fehler dieser Art immer mit den folgenden Schritten:
Auf dem Server: sshd -Ddp 22222
Auf dem Client: ssh -p 22222 user@server
Und bewundere dann die Meldungen auf der Server-Seite, die etwas mit den Public-Keys, bzw. den authorized_keys file anmeckert.
Danke für den Hinweis! Ich habe es jedoch jetzt von "jens" aus wir folgt gemacht: ssh -v -v -v eta Dabei erhalte ich folgende "tolle" Fehlermeldung: Hirbei muss ich sagen, dass ich eigentlich mehrer ssh-Verbindungen aufbauen muss: 1. jens => eta (funktioniert nicht) 2. eta => jens (Verbindung funktioniert!) 3. jens => jens (funktioniert nicht) 4. eta => eta (funktioniert nicht) Daher existieren auch bereits Eintragungen für die restlichen Verbindungen. Dank dieser Hilfe kann ich jedoch erkennen, dass an einer Stelle (direkt oberhalb von den "!!!!!!!!!!!!!!!!!!!") der richtige Schlüssel verwendet wird; jedoch mein Rechner leider keine Antwort erhält. Über Hilfe freue ich mich weiterhin! ;-)) DANKE! (die newsgroup ist wirklich klasse!) jens@jens:~/.ssh> ssh -v -v -v eta OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f 4064: debug1: Reading configuration data /home/jens/.ssh/config 4064: debug1: Applying options for eta 4064: debug1: Reading configuration data /etc/ssh/ssh_config 4064: debug1: Applying options for * 4064: debug1: Rhosts Authentication disabled, originating port will not be trusted. 4064: debug1: ssh_connect: needpriv 0 4064: debug1: Connecting to eta [192.168.0.52] port 22. 4064: debug1: Connection established. 4064: debug1: identity file jens:/home/jens/.ssh/jenseta type -1 4064: debug1: identity file /home/jens/.ssh/identity type -1 4064: debug1: identity file /home/jens/.ssh/id_rsa type -1 4064: debug1: identity file /home/jens/.ssh/id_dsa type -1 4064: debug3: Not a RSA1 key file /home/jens/.ssh/jenseta. 4064: debug2: key_type_from_name: unknown key type '-----BEGIN' 4064: debug3: key_read: no key found 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug3: key_read: no space 4064: debug2: key_type_from_name: unknown key type '-----END' 4064: debug3: key_read: no key found 4064: debug1: identity file /home/jens/.ssh/jenseta type 2 4064: debug1: identity file /home/jens/.ssh/jensjens type -1 4064: debug1: identity file /home/jens/.ssh/etajens type -1 4064: debug1: identity file /home/jens/.ssh/etaeta type -1 4064: debug1: Remote protocol version 1.99, remote software version OpenSSH_3.5p1 4064: debug1: match: OpenSSH_3.5p1 pat OpenSSH* 4064: debug1: Enabling compatibility mode for protocol 2.0 4064: debug1: Local version string SSH-2.0-OpenSSH_3.5p1 4064: debug1: SSH2_MSG_KEXINIT sent 4064: debug1: SSH2_MSG_KEXINIT received 4064: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 4064: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss 4064: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se 4064: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se 4064: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 4064: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 4064: debug2: kex_parse_kexinit: zlib,none 4064: debug2: kex_parse_kexinit: zlib,none 4064: debug2: kex_parse_kexinit: 4064: debug2: kex_parse_kexinit: 4064: debug2: kex_parse_kexinit: first_kex_follows 0 4064: debug2: kex_parse_kexinit: reserved 0 4064: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 4064: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss 4064: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se 4064: debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se 4064: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 4064: debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 4064: debug2: kex_parse_kexinit: none,zlib 4064: debug2: kex_parse_kexinit: none,zlib 4064: debug2: kex_parse_kexinit: 4064: debug2: kex_parse_kexinit: 4064: debug2: kex_parse_kexinit: first_kex_follows 0 4064: debug2: kex_parse_kexinit: reserved 0 4064: debug2: mac_init: found hmac-md5 4064: debug1: kex: server->client aes128-cbc hmac-md5 zlib 4064: debug2: mac_init: found hmac-md5 4064: debug1: kex: client->server aes128-cbc hmac-md5 zlib 4064: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent 4064: debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP 4064: debug1: dh_gen_key: priv key bits set: 140/256 4064: debug1: bits set: 1571/3191 4064: debug1: SSH2_MSG_KEX_DH_GEX_INIT sent 4064: debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY 4064: debug3: check_host_in_hostfile: filename /home/jens/.ssh/known_hosts 4064: debug3: check_host_in_hostfile: match line 1 4064: debug3: check_host_in_hostfile: filename /home/jens/.ssh/known_hosts 4064: debug3: check_host_in_hostfile: match line 1 4064: debug1: Host 'eta' is known and matches the RSA host key. 4064: debug1: Found key in /home/jens/.ssh/known_hosts:1 4064: debug1: bits set: 1569/3191 4064: debug1: ssh_rsa_verify: signature correct 4064: debug1: kex_derive_keys 4064: debug1: newkeys: mode 1 4064: debug1: Enabling compression at level 6. 4064: debug1: SSH2_MSG_NEWKEYS sent 4064: debug1: waiting for SSH2_MSG_NEWKEYS 4064: debug1: newkeys: mode 0 4064: debug1: SSH2_MSG_NEWKEYS received 4064: debug1: done: ssh_kex2. 4064: debug1: send SSH2_MSG_SERVICE_REQUEST 4064: debug1: service_accept: ssh-userauth 4064: debug1: got SSH2_MSG_SERVICE_ACCEPT 4064: debug1: authentications that can continue: publickey,password 4064: debug3: start over, passed a different list publickey,password 4064: debug3: preferred publickey,keyboard-interactive,password 4064: debug3: authmethod_lookup publickey 4064: debug3: remaining preferred: keyboard-interactive,password 4064: debug3: authmethod_is_enabled publickey 4064: debug1: next auth method to try is publickey 4064: debug1: try privkey: jens:/home/jens/.ssh/jenseta 4064: debug3: no such identity: jens:/home/jens/.ssh/jenseta 4064: debug1: try privkey: /home/jens/.ssh/identity 4064: debug3: no such identity: /home/jens/.ssh/identity 4064: debug1: try privkey: /home/jens/.ssh/id_rsa 4064: debug3: no such identity: /home/jens/.ssh/id_rsa 4064: debug1: try privkey: /home/jens/.ssh/id_dsa 4064: debug3: no such identity: /home/jens/.ssh/id_dsa 4064: debug1: try pubkey: /home/jens/.ssh/jenseta 4064: debug3: send_pubkey_test 4064: debug2: we sent a publickey packet, wait for reply !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 4064: debug1: authentications that can continue: publickey,password 4064: debug1: try privkey: /home/jens/.ssh/jensjens 4064: debug3: no such identity: /home/jens/.ssh/jensjens 4064: debug1: try privkey: /home/jens/.ssh/etajens 4064: debug3: no such identity: /home/jens/.ssh/etajens 4064: debug1: try privkey: /home/jens/.ssh/etaeta 4064: debug3: no such identity: /home/jens/.ssh/etaeta 4064: debug2: we did not send a packet, disable method 4064: debug3: authmethod_lookup password 4064: debug3: remaining preferred: ,password 4064: debug3: authmethod_is_enabled password 4064: debug1: next auth method to try is password
Jens Ritzert wrote:
Dank dieser Hilfe kann ich jedoch erkennen, dass an einer Stelle (direkt oberhalb von den "!!!!!!!!!!!!!!!!!!!") der richtige Schlüssel verwendet wird; jedoch mein Rechner leider keine Antwort erhält.
Ja, sehe ich auch so. -> Server-Problem
jens@jens:~/.ssh> ssh -v -v -v eta OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f ... 4064: debug3: Not a RSA1 key file /home/jens/.ssh/jenseta. ... 4064: debug1: identity file /home/jens/.ssh/jenseta type 2
Sieht ok aus.
4064: debug1: try pubkey: /home/jens/.ssh/jenseta 4064: debug3: send_pubkey_test 4064: debug2: we sent a publickey packet, wait for reply !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Weitergehen muss es dann mit debug1: input_userauth_pk_ok: Sonst hat der Server den Key abgelehnt, bzw. keinen gueltigen Eintrag in der authorized_keys gefunden. Mach auf eta mal "sshd -dDp 22222" und auf jens "ssh -vp 22222" (ein -v reicht dicke aus) -- Have fun, Peter
Habe auf "eta" "sshd -dDp 22222" mit folgender Antwort durchgeführt: 3323: debug1: sshd version OpenSSH_3.5p1 3323: debug1: private host key: #0 type 0 RSA1 3323: debug1: read PEM private key done: type RSA 3323: debug1: private host key: #1 type 1 RSA 3323: debug1: read PEM private key done: type DSA 3323: debug1: private host key: #2 type 2 DSA 3323: debug1: Bind to port 22222 on ::. 3323: Server listening on :: port 22222. 3323: Generating 768 bit RSA key. 3323: RSA key generation complete. Auf "jens" erhielt mit dem Befehl "ssh -v [-p22222]" (bei "ssh -vp 22222" erhalte ich nur die man-page von ssh) folgende Antwort: OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f 4668: debug1: Reading configuration data /etc/ssh/ssh_config 4668: debug1: Applying options for * 4668: debug1: Rhosts Authentication disabled, originating port will not be trusted. 4668: debug1: ssh_connect: needpriv 0 4668: ssh: [-p22222]: Name or service not known .... was sagt mir das nun??? Peter Wiersig schrieb:
Jens Ritzert wrote:
Dank dieser Hilfe kann ich jedoch erkennen, dass an einer Stelle (direkt oberhalb von den "!!!!!!!!!!!!!!!!!!!") der richtige Schlüssel verwendet wird; jedoch mein Rechner leider keine Antwort erhält.
Ja, sehe ich auch so. -> Server-Problem
jens@jens:~/.ssh> ssh -v -v -v eta OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090609f ... 4064: debug3: Not a RSA1 key file /home/jens/.ssh/jenseta. ... 4064: debug1: identity file /home/jens/.ssh/jenseta type 2
Sieht ok aus.
4064: debug1: try pubkey: /home/jens/.ssh/jenseta 4064: debug3: send_pubkey_test 4064: debug2: we sent a publickey packet, wait for reply !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Weitergehen muss es dann mit debug1: input_userauth_pk_ok:
Sonst hat der Server den Key abgelehnt, bzw. keinen gueltigen Eintrag in der authorized_keys gefunden.
Mach auf eta mal "sshd -dDp 22222" und auf jens "ssh -vp 22222" (ein -v reicht dicke aus)
Jens Ritzert wrote:
Habe auf "eta" "sshd -dDp 22222" mit folgender Antwort durchgeführt:
3323: debug1: sshd version OpenSSH_3.5p1 .... 3323: RSA key generation complete.
hiernach kommen dann Meldungen, sobald der Client connected.
Auf "jens" erhielt mit dem Befehl "ssh -v [-p22222]" (bei "ssh -vp 22222" erhalte ich nur die man-page von ssh) folgende Antwort:
a) funktioniert -vp 22222 bei mir b) kann man das auch "-v -p 22222" schreiben. Dein ssh-Aufruf hat sich nicht mit der Debug-Instanz vom sshd verbunden. Bitte nochmal. Du hast ja ssh V3.5p1. Vielleicht ist der -p switch gewandert: $ ssh -? 2>&1 | grep port -p port Connect to this port. Server must be on the same port. -- Have fun, Peter
Peter Wiersig schrieb:
Jens Ritzert wrote:
Habe auf "eta" "sshd -dDp 22222" mit folgender Antwort durchgeführt:
3323: debug1: sshd version OpenSSH_3.5p1 .... 3323: RSA key generation complete.
hiernach kommen dann Meldungen, sobald der Client connected.
Auf "jens" erhielt mit dem Befehl "ssh -v [-p22222]" (bei "ssh -vp 22222" erhalte ich nur die man-page von ssh) folgende Antwort:
a) funktioniert -vp 22222 bei mir b) kann man das auch "-v -p 22222" schreiben.
Dein ssh-Aufruf hat sich nicht mit der Debug-Instanz vom sshd verbunden. Bitte nochmal.
Du hast ja ssh V3.5p1. Vielleicht ist der -p switch gewandert:
$ ssh -? 2>&1 | grep port -p port Connect to this port. Server must be on the same port.
.... sorry .... der linux-experte bin ich dann doch noch nicht ...... sämtlich andere Varianten ( "-vp 22222" und "-v -p 22222") funktionierten nicht (man-page). ...... was soll ich jetzt wie wo machen? (.... ich glaub bei mir funktioniert gar nichts ....) .... aber egal .... das ganze nervt mich jetzt bereits seit zwei tagen und geh? jetzt erst mal in den biergarten ..... *gg schönen abend noch!
Peter Wiersig schrieb:
Jens Ritzert wrote:
...... was soll ich jetzt wie wo machen?
Noch mal auf der Serverseite "sshd -dDp 22222" starten und auf dem Rechner jens "ssh -v -p 22222 eta" eingeben.
Den Befehl auf der Serverseite kann ich nur als root starten. Ist das normal? Ich habe jetzt sshd auf "eta" als root ausgeführt und ssh auf "jens" als Benutzer. Auf der Serverseite erhalte ich nach manueller eingabe des Passwortes und einfachen exit: Noch folgender Hinweis: Die IP XX. ..... .65 ist "jens" Die IP XXX. .... . 52 ist "eta". eta:/home/jens/.ssh # sshd -dDp 22222 6001: debug1: sshd version OpenSSH_3.5p1 6001: debug1: private host key: #0 type 0 RSA1 6001: debug1: read PEM private key done: type RSA 6001: debug1: private host key: #1 type 1 RSA 6001: debug1: read PEM private key done: type DSA 6001: debug1: private host key: #2 type 2 DSA 6001: debug1: Bind to port 22222 on ::. 6001: Server listening on :: port 22222. 6001: Generating 768 bit RSA key. 6001: RSA key generation complete. 6001: debug1: Server will not fork when running in debugging mode. 6001: Connection from ::ffff:192.168.0.65 port 32899 6001: debug1: Client protocol version 2.0; client software version OpenSSH_3.5p1 6001: debug1: match: OpenSSH_3.5p1 pat OpenSSH* 6001: debug1: Enabling compatibility mode for protocol 2.0 6001: debug1: Local version string SSH-1.99-OpenSSH_3.5p1 6003: debug1: permanently_set_uid: 71/65 6003: debug1: list_hostkey_types: ssh-rsa,ssh-dss 6003: debug1: SSH2_MSG_KEXINIT sent 6003: debug1: SSH2_MSG_KEXINIT received 6003: debug1: kex: client->server aes128-cbc hmac-md5 zlib 6003: debug1: kex: server->client aes128-cbc hmac-md5 zlib 6003: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received 6003: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent 6003: debug1: dh_gen_key: priv key bits set: 141/256 6003: debug1: bits set: 1606/3191 6003: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT 6003: debug1: bits set: 1603/3191 6003: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent 6003: debug1: kex_derive_keys 6003: debug1: newkeys: mode 1 6003: debug1: Enabling compression at level 6. 6003: debug1: SSH2_MSG_NEWKEYS sent 6003: debug1: waiting for SSH2_MSG_NEWKEYS 6003: debug1: newkeys: mode 0 6003: debug1: SSH2_MSG_NEWKEYS received 6003: debug1: KEX done 6003: debug1: userauth-request for user jens service ssh-connection method none 6003: debug1: attempt 0 failures 0 6001: debug1: Starting up PAM with username "jens" 6001: debug1: PAM setting rhost to "jens.sla.maschinenbau.tu-darmstadt.de" 6001: Failed none for jens from ::ffff:192.168.0.65 port 32899 ssh2 6003: Failed none for jens from ::ffff:192.168.0.65 port 32899 ssh2 6003: debug1: userauth-request for user jens service ssh-connection method publickey 6003: debug1: attempt 1 failures 1 6003: debug1: test whether pkalg/pkblob are acceptable 6001: debug1: temporarily_use_uid: 2011/100 (e=0/0) 6001: debug1: trying public key file /home/jens/.ssh/authorized_keys 6001: debug1: restore_uid: 0/0 6001: debug1: temporarily_use_uid: 2011/100 (e=0/0) 6001: debug1: trying public key file /home/jens/.ssh/authorized_keys2 6001: Authentication refused: bad ownership or modes for directory /home/jens 6001: debug1: restore_uid: 0/0 6003: Failed publickey for jens from ::ffff:192.168.0.65 port 32899 ssh2 6003: debug1: userauth-request for user jens service ssh-connection method publickey 6003: debug1: attempt 2 failures 2 6003: debug1: test whether pkalg/pkblob are acceptable 6001: debug1: temporarily_use_uid: 2011/100 (e=0/0) 6001: debug1: trying public key file /home/jens/.ssh/authorized_keys 6001: debug1: restore_uid: 0/0 6001: debug1: temporarily_use_uid: 2011/100 (e=0/0) 6001: debug1: trying public key file /home/jens/.ssh/authorized_keys2 6001: Authentication refused: bad ownership or modes for directory /home/jens 6001: debug1: restore_uid: 0/0 6003: Failed publickey for jens from ::ffff:192.168.0.65 port 32899 ssh2 6003: debug1: userauth-request for user jens service ssh-connection method password 6003: debug1: attempt 3 failures 3 6001: debug1: PAM Password authentication accepted for user "jens" 6003: Accepted password for jens from ::ffff:192.168.0.65 port 32899 ssh2 6001: Accepted password for jens from ::ffff:192.168.0.65 port 32899 ssh2 6001: debug1: monitor_child_preauth: jens has been authenticated by privileged process 6004: debug1: PAM establishing creds 6004: debug1: permanently_set_uid: 2011/100 6004: debug1: newkeys: mode 0 6004: debug1: newkeys: mode 1 6004: debug1: Entering interactive session for SSH2. 6004: debug1: fd 7 setting O_NONBLOCK 6004: debug1: fd 8 setting O_NONBLOCK 6004: debug1: server_init_dispatch_20 6004: debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 6004: debug1: input_session_request 6004: debug1: channel 0: new [server-session] 6004: debug1: session_new: init 6004: debug1: session_new: session 0 6004: debug1: session_open: channel 0 6004: debug1: session_open: session 0: link with channel 0 6004: debug1: server_input_channel_open: confirm session 6004: debug1: server_input_channel_req: channel 0 request pty-req reply 0 6004: debug1: session_by_channel: session 0 channel 0 6004: debug1: session_input_channel_req: session 0 req pty-req 6004: debug1: Allocating pty. 6001: debug1: session_new: init 6001: debug1: session_new: session 0 6004: debug1: session_pty_req: session 0 alloc /dev/pts/3 6004: debug1: server_input_channel_req: channel 0 request x11-req reply 0 6004: debug1: session_by_channel: session 0 channel 0 6004: debug1: session_input_channel_req: session 0 req x11-req 6004: debug1: fd 11 setting O_NONBLOCK 6004: debug1: channel 1: new [X11 inet listener] 6004: debug1: fd 12 setting O_NONBLOCK 6004: debug1: channel 2: new [X11 inet listener] 6004: debug1: server_input_channel_req: channel 0 request shell reply 0 6004: debug1: session_by_channel: session 0 channel 0 6004: debug1: session_input_channel_req: session 0 req shell 6004: debug1: temporarily_use_uid: 2011/100 (e=2011/100) 6004: debug1: No GSSAPI credentials stored 6004: debug1: restore_uid: (unprivileged) 6004: debug1: PAM setting tty to "/dev/pts/3" 6004: debug1: PAM establishing creds 6005: debug1: Setting controlling tty using TIOCSCTTY. 6004: debug1: fd 4 setting TCP_NODELAY 6004: debug1: channel 0: rfd 10 isatty 6004: debug1: fd 10 setting O_NONBLOCK 6004: debug1: Received SIGCHLD. 6004: debug1: session_by_pid: pid 6005 6004: debug1: session_exit_message: session 0 channel 0 pid 6005 6004: debug1: channel request 0: exit-status 6004: debug1: session_exit_message: release channel 0 6004: debug1: channel 0: write failed 6004: debug1: channel 0: close_write 6004: debug1: channel 0: output open -> closed 6004: debug1: session_close: session 0 pid 6005 6004: debug1: channel 0: read<=0 rfd 10 len -1 6004: debug1: channel 0: read failed 6004: debug1: channel 0: close_read 6004: debug1: channel 0: input open -> drain 6004: debug1: channel 0: ibuf empty 6004: debug1: channel 0: send eof 6004: debug1: channel 0: input drain -> closed 6004: debug1: channel 0: send close 6001: debug1: session_by_tty: session 0 tty /dev/pts/3 6001: debug1: session_pty_cleanup: session 0 release /dev/pts/3 6004: debug1: channel 0: rcvd close 6004: debug1: channel 0: is dead 6004: debug1: channel 0: garbage collecting 6004: debug1: channel_free: channel 0: server-session, nchannels 3 6004: Connection closed by ::ffff:192.168.0.65 6004: debug1: channel_free: channel 1: X11 inet listener, nchannels 2 6004: debug1: channel_free: channel 2: X11 inet listener, nchannels 1 6004: debug1: krb5_cleanup_proc called 6004: Closing connection to ::ffff:192.168.0.65 eta:/home/jens/.ssh # Auf der Clientseite steht nach weiterer manuellen Eingabe des Passwortes: 2793: debug1: ssh-userauth2 successful: method password 2793: debug1: channel 0: new [client-session] 2793: debug1: send channel open 0 2793: debug1: Entering interactive session. 2793: debug1: ssh_session2_setup: id 0 2793: debug1: channel request 0: pty-req 2793: debug1: Requesting X11 forwarding with authentication spoofing. 2793: debug1: channel request 0: x11-req 2793: debug1: channel request 0: shell 2793: debug1: fd 3 setting TCP_NODELAY 2793: debug1: channel 0: open confirm rwindow 0 rmax 32768 Last login: Sat Aug 2 16:11:24 2003 from console Have a lot of fun... 5981: debug1: No GSSAPI credentials stored Environment: USER=jens LOGNAME=jens HOME=/home/jens PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/mail/jens SHELL=/bin/bash SSH_CLIENT=::ffff:192.168.0.65 32897 22222 SSH_CONNECTION=::ffff:192.168.0.65 32897 ::ffff:192.168.0.52 22222 SSH_TTY=/dev/pts/3 TERM=xterm DISPLAY=localhost:10.0 Running /usr/X11R6/bin/xauth add unix:10.0 MIT-MAGIC-COOKIE-1 e82082a0bade66b2742c90449ec3e6f5 5981: debug1: Received SIGCHLD. ..... mir sagt das ganze leider gar nichts mehr ...... Grüsse Jens
Jens Ritzert wrote:
Den Befehl auf der Serverseite kann ich nur als root starten. Ist das normal?
Ja, je nach Server-Konfiguration sind root-Rechte noetig.
Ich habe jetzt sshd auf "eta" als root ausgeführt und ssh auf "jens" als Benutzer. ... 6001: debug1: trying public key file /home/jens/.ssh/authorized_keys2 6001: Authentication refused: bad ownership or modes for directory /home/jens
Da isses ja schon. /home/jens auf eta ist group, bzw. other-writeable. mach mal "ls -ld /home/jens" und aendere per "chmod o-w /home/jens", bzw. per "chmod g-w /home/jens" die Veraenderungsrechte auf dein Home-Verzeichnis auf ein fuer ssh akzeptables Sicherheitsniveau. -- Have fun, Peter
SUUUUUUPER .... das war?s !!!!! Besten Dank!!!! Auf den Fehler wäre ich nie gekommen! Grüsse Jens
Hallo auch, Am Freitag, 1. August 2003 14:25 schrieb Jens Ritzert:
Hallo! Ich versuche seit einiger Zeit von meinem Laptop (jens) hin zu meinem Arbeitsplatzrechner (eta) eine ssl-Verbindung ohne Passwort zu erzeugen. Beide Rechner laufen mit Suse 8.2 und besitzen auch das Update auf OpenSSH_3.5p1-68. Zuerst erzeuge ich auf "jens" einen entsprechenden Schlüssel mit ssh-keygen -t dsa Als Datei geben ich "/home/jens/.ssh/jenstoeta" an. Als Passphrase möchte ich zunächst nichts vorgeben (Eine Passphrase mit einer Verwaltung über einen ssh-Agenten möchte ich später erzeugen, ist jedoch jetzt für mein Problem nicht von belang.) und bestätige daher zweimal mit "return". Den erzeugten Publickey "jenstoeta.pub" kopiere ich nach "eta:/home/jens/.ssh/authority_keys2" Anschließend setze ich auf beiden Rechner noch die Rechte wie folgt: chmod 700 /home/jens/.ssh chmod 600 /home/jens/.ssh/*
Hmm, imho heisst der file "authorized_keys2", nicht "authority_keys2", versuch das mal. MfG, Bernd -- One OS to rule them all, one OS to find them. One OS to bring them all, and in the darkness bind them In the land of Redmond, where the shadows lie.
Bernd Tannenbaum schrieb:
Hallo auch,
Am Freitag, 1. August 2003 14:25 schrieb Jens Ritzert:
Hallo! Ich versuche seit einiger Zeit von meinem Laptop (jens) hin zu meinem Arbeitsplatzrechner (eta) eine ssl-Verbindung ohne Passwort zu erzeugen. Beide Rechner laufen mit Suse 8.2 und besitzen auch das Update auf OpenSSH_3.5p1-68. Zuerst erzeuge ich auf "jens" einen entsprechenden Schlüssel mit ssh-keygen -t dsa Als Datei geben ich "/home/jens/.ssh/jenstoeta" an. Als Passphrase möchte ich zunächst nichts vorgeben (Eine Passphrase mit einer Verwaltung über einen ssh-Agenten möchte ich später erzeugen, ist jedoch jetzt für mein Problem nicht von belang.) und bestätige daher zweimal mit "return". Den erzeugten Publickey "jenstoeta.pub" kopiere ich nach "eta:/home/jens/.ssh/authority_keys2" Anschließend setze ich auf beiden Rechner noch die Rechte wie folgt: chmod 700 /home/jens/.ssh chmod 600 /home/jens/.ssh/*
Hmm, imho heisst der file "authorized_keys2", nicht "authority_keys2", versuch das mal.
MfG, Bernd
Danke für den Hinweis ...... war aber wie gesagt nur ein Schreibfehler von mir. Wichtig ist jedoch vielleicht noch folgendes: Ich befinde mich mit beiden Rechnern hinter einer Firewall und wir haben auch ein Gateway. Ich kann jedoch sonst immer die anderen Rechner normal anpingen und eine ssh-mit-Passwort-Verbindung aufbauen. Kennt sich jemand mit Problemen im richtigen Netzwerk und ssh (ohne Passwort) aus? Grüsse, Jens
participants (3)
-
Bernd Tannenbaum -
Jens Ritzert -
Peter Wiersig