Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Thu, 26 Jan 2006 21:41:07 +0100): > On 26.01.06 21:21:32, Richard Mittendorfer wrote: > > Also sprach Andreas Pakulat <[EMAIL PROTECTED]> (Thu, 26 Jan 2006 > > 20:47:08 +0100): > > > Nicht falsch, der sshd erlaubt in der Default-Konfiguration kein > > > X11-Forward. Schau mal in die sshd_config auf dem entfernten > > > Rechner, dort muesste irgendwo eine X11Forward Option stehen. Wenn > > > die aktiviert ist geht ssh -X auch und man muss nicht mehr extra > > > mit xauth den Schluessel exportieren. Das machst du zwar bestimmt > > > in .xsession, aber sowas kann ich hier nicht benutzen.. > > > > X11Forwarding Yes > > X11DisplayOffset 10 > > Das sollte reichen.
Also teste ich das mal mit -nolisten tcp: Hmm. Firewall aus. Selbiges. Im remote auth log (level DEBUG): 192.168.2.52(libre) X -> 192.168.1.51(breez) sshd sshd beim Login: sshd[754]: debug1: Forked child 1584. sshd[1584]: debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7 sshd[1584]: debug1: inetd sockets after dupping: 3, 3 sshd[1584]: Connection from 192.168.2.52 port 3427 sshd[1584]: debug1: Client protocol version 2.0; client software version OpenSSH_ sshd[1584]: debug1: match: OpenSSH_4.2p1 Debian-5 pat OpenSSH* sshd[1584]: debug1: Enabling compatibility mode for protocol 2.0 sshd[1584]: debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-5 sshd[1584]: debug1: Miscellaneous failure\nNo such file or directory\n sshd[1584]: debug1: PAM: initializing for "ritch" sshd[1584]: debug1: PAM: setting PAM_RHOST to "libre.w.lan" sshd[1584]: debug1: PAM: setting PAM_TTY to "ssh" sshd[1584]: Failed none for ritch from 192.168.2.52 port 3427 ssh2 sshd[1584]: debug1: temporarily_use_uid: 1000/1000 (e=0/0 sshd[1584]: debug1: trying public key file /home/ritch/.ssh/authorized_keys sshd[1584]: debug1: matching key found: file /home/ritch/.ssh/authorized_keys, li sshd[1584]: Found matching RSA key: xxxxxxxxxxxx sshd[1584]: debug1: restore_uid: 0/0 sshd[1584]: debug1: temporarily_use_uid: 1000/1000 (e=0/0) sshd[1584]: debug1: trying public key file /home/ritch/.ssh/authorized_keys sshd[1584]: debug1: matching key found: file /home/ritch/.ssh/authorized_keys, li sshd[1584]: Found matching RSA key: xxxxxxxxxxxx sshd[1584]: debug1: restore_uid: 0/0 sshd[1584]: debug1: ssh_rsa_verify: signature correct sshd[1584]: debug1: do_pam_account: called sshd[1584]: Accepted publickey for ritch from 192.168.2.52 port 3427 ssh2 sshd[1584]: debug1: monitor_child_preauth: ritch has been authenticated by privil sshd[1588]: (pam_unix) session opened for user ritch by (uid=0) sshd[1588]: debug1: PAM: reinitializing credentials sshd[1588]: debug1: permanently_set_uid: 1000/1000 sshd[1588]: debug1: Entering interactive session for SSH2. sshd[1588]: debug1: server_init_dispatch_20 sshd[1588]: debug1: server_input_channel_open: ctype session rchan 0 win 65536 ma sshd[1588]: debug1: input_session_request sshd[1588]: debug1: channel 0: new [server-session] sshd[1588]: debug1: session_new: init sshd[1588]: debug1: session_new: session 0 sshd[1588]: debug1: session_open: channel 0 sshd[1588]: debug1: session_open: session 0: link with channel 0 sshd[1588]: debug1: server_input_channel_open: confirm session sshd[1588]: debug1: server_input_channel_req: channel 0 request x11-req reply 0 sshd[1588]: debug1: session_by_channel: session 0 channel 0 sshd[1588]: debug1: session_input_channel_req: session 0 req x11-req .. sshd[1588]: debug1: x11_create_display_inet: Socket family 10 not supported Das sieht nicht gut aus. Was brauche ich dafuer? im Kernel? .. sshd[1588]: debug1: channel 1: new [X11 inet listener] sshd[1588]: debug1: server_input_channel_req: channel 0 request pty-req reply 0 sshd[1588]: debug1: session_by_channel: session 0 channel 0 sshd[1588]: debug1: session_input_channel_req: session 0 req pty-req sshd[1588]: debug1: Allocating pty. sshd[1584]: debug1: session_new: init sshd[1584]: debug1: session_new: session 0 sshd[1588]: debug1: session_pty_req: session 0 alloc /dev/pts/0 sshd[1588]: debug1: server_input_channel_req: channel 0 request env reply 0 sshd[1588]: debug1: session_by_channel: session 0 channel 0 sshd[1588]: debug1: session_input_channel_req: session 0 req env sshd[1588]: debug1: server_input_channel_req: channel 0 request env reply 0 sshd[1588]: debug1: session_by_channel: session 0 channel 0 sshd[1588]: debug1: session_input_channel_req: session 0 req env sshd[1588]: debug1: server_input_channel_req: channel 0 request shell reply 0 sshd[1588]: debug1: session_by_channel: session 0 channel 0 sshd[1588]: debug1: session_input_channel_req: session 0 req shell sshd[1588]: debug1: PAM: setting PAM_TTY to "/dev/pts/0" sshd[1593]: debug1: Setting controlling tty using TIOCSCTTY. sshd[1593]: debug1: Received SIGCHLD. Login: [EMAIL PROTECTED]:~$ ssh -X -v breez OpenSSH_4.2p1 Debian-5, OpenSSL 0.9.8a 11 Oct 2005 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to breez [192.168.1.51] port 22. debug1: Connection established. debug1: identity file /home/ritch/.ssh/identity type -1 debug1: identity file /home/ritch/.ssh/id_rsa type 1 debug1: identity file /home/ritch/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_4.2p1 Debian-5 debug1: match: OpenSSH_4.2p1 Debian-5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2p1 Debian-5 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none 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 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'breez' is known and matches the RSA host key. debug1: Found key in /home/ritch/.ssh/known_hosts:26 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/ritch/.ssh/identity debug1: Offering public key: /home/ritch/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 149 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Entering interactive session. debug1: Requesting X11 forwarding with authentication spoofing. debug1: Sending environment. debug1: Sending env LC_ALL = [EMAIL PROTECTED] debug1: Sending env LANG = [EMAIL PROTECTED] [EMAIL PROTECTED]:~$ xterm debug1: client_input_channel_open: ctype x11 rchan 2 win 65536 max 16384 debug1: client_request_x11: request from 127.0.0.1 33491 debug1: channel 1: new [x11] debug1: confirm x11 X11 connection rejected because of wrong authentication. debug1: channel 1: free: x11, nchannels 2 X connection to localhost:10.0 broken (explicit kill or server shutdown) [EMAIL PROTECTED]:~$ echo $DISPLAY localhost:10.0 # ist das der lokale ssh tunnel? ls -l /dev/pts crw--w---- 1 ritch tty 136, 0 Jan 26 22:41 0 crw------- 1 root tty 136, 1 Jan 26 22:42 1 crw------- 1 root tty 136, 2 Jan 26 22:42 2 (auf beiden seiten) UsePam mal auskommentiert. Selbiges. > > Noe, es is' was anderes mit dem ich mich vor langer Zeit gespielt > > und scheinbar kaputt gemacht hab. > > Moeglich, das sshd-Log sollte dir mehr liefern und ssh -v. Ich's kanns nicht wirklich interpretieren. > > Ich denke es wird an der Firewall oder am > > Routing an einem der Geraete dazwischen liegen. > > Beides kann nicht sein, denn ssh -X schickt alle "X11-Daten" durch den > ssh-Tunnel. Sprich wenn ssh geht, sollte auch ssh -X gehen. Ausser > eben du hast am sshd oder am XServer "rumgespielt". Weder Firewall > noch Router koennen die X11-Daten verändern, das ist ja der Sinn von > ssh - an die Daten kommt kein 3. ran. Ist auch meine Ansicht, da ssh (ohne X11Fwd) ja funkt. > > Ich hab ssh -X mal absichtlich abgeschalten weil die Clients recht > > schwach auf der Brust sind (zwei MIPS und ein P266), ich auf > > letzterem Videos schau und mir die Verschluesselung sparen wollte. > > Viel kanns nicht sein, hab' aber so spontan keine Ahnung was es war. > > :( > > Hmm, ich hab hier nur nen PIII/500, an den P1 133 komm ich nicht, da > ist auch momentan kein Linux drauf... Aber sooo viel sollte die > ssh-Verschluesselung nicht ausmachen... Viel sicher nicht, aber es hilft. Hohe Aufloesungen bekomm' ich auch so nicht uebers schlappe wlan. Lokal abgespielt ist's aber alles andere als lustig. > Andreas sl ritch