Re: Fw: Re: Starten eines Prog. auf anderem Rechner via X11 Terminal
Also sprach Andreas Pakulat <apaku@gmx.de> (Thu, 26 Jan 2006 21:41:07
+0100):
> On 26.01.06 21:21:32, Richard Mittendorfer wrote:
> > Also sprach Andreas Pakulat <apaku@gmx.de> (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:
ritch@libre:~$ 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 = de_AT@euro
debug1: Sending env LANG = de_AT@euro
ritch@breez:~$ 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)
ritch@breez:~$ 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
Reply to: