Re: X11 Forward mit OpenSuse 12.2
[Fullquote beabsichtigt, bitte keine privaten Mails] Am 09.10.2012 um 16:22 schrieb Karl Sinn <news@budostore.de>:
Hallo,
Am 09.10.2012 15:43, schrieb Rainer Sokoll:
sshd -D -d -p <portnummer>"
Das hat nicht geklappt: Server: /usr/sbin/sshd -D -d -p 1234 debug1: sshd version OpenSSH_6.0p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: read PEM private key done: type ECDSA debug1: private host key: #2 type 3 ECDSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-p' debug1: rexec_argv[4]='1234' Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 1234 on 0.0.0.0. Server listening on 0.0.0.0 port 1234. debug1: Bind to port 1234 on ::. Server listening on :: port 1234.
Client: ssh -vX 192.168.2.6:1234 OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * ssh: Could not resolve hostname 192.168.2.6:1234: Name or service not known
Gruß Karl
ssh -X -vv -p 1234 192.168.2.6 Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo,
ssh -X -vv -p 1234 192.168.2.6
das hat funktioniert. Es gibt auch eine Fehlermeldung. Ich weiss aber nicht was ich damit anfangen soll. Gruß Karl P.S.: sorry, ich hab jetzt erst gemerkt dass meine Antworten als Private Mail rausgingen, Ich schicke wieder an die Liste ------------------------------------ Client-Seite---------------------------- ssh -X -vv -p 1234 192.168.2.6 OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.2.6 [192.168.2.6] port 1234. debug1: Connection established. debug1: identity file /home/karl/.ssh/id_rsa type -1 debug1: identity file /home/karl/.ssh/id_rsa-cert type -1 debug1: identity file /home/karl/.ssh/id_dsa type -1 debug1: identity file /home/karl/.ssh/id_dsa-cert type -1 debug1: identity file /home/karl/.ssh/id_ecdsa type -1 debug1: identity file /home/karl/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0 debug1: match: OpenSSH_6.0 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,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: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib debug2: kex_parse_kexinit: none,zlib@openssh.com,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_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA 96:bd:08:48:83:53:b7:5f:f7:8f:9b:b2:8d:8d:18:7e debug1: checking without port identifier debug1: Host '192.168.2.6' is known and matches the ECDSA host key. debug1: Found key in /home/karl/.ssh/known_hosts:1 debug1: found matching key w/out port debug1: ssh_ecdsa_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: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /home/karl/.ssh/id_rsa ((nil)) debug2: key: /home/karl/.ssh/id_dsa ((nil)) debug2: key: /home/karl/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/karl/.ssh/id_rsa debug1: Trying private key: /home/karl/.ssh/id_dsa debug1: Trying private key: /home/karl/.ssh/id_ecdsa debug2: we did not send a packet, disable method 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 Password: debug2: input_userauth_info_req debug2: input_userauth_info_req: num_prompts 0 debug1: Authentication succeeded (keyboard-interactive). Authenticated to 192.168.2.6 ([192.168.2.6]:1234). debug1: channel 0: new [client-session] debug2: channel 0: send open debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug2: callback start debug2: x11_get_proto: /usr/bin/xauth list :0.0 2>/dev/null debug1: Requesting X11 forwarding with authentication spoofing. debug2: channel 0: request x11-req confirm 1 debug2: client_session2_setup: id 0 debug2: fd 3 setting TCP_NODELAY debug2: channel 0: request pty-req confirm 1 debug1: Sending environment. debug1: Sending env LANG = de_DE.UTF-8 debug2: channel 0: request env confirm 0 debug2: channel 0: request shell confirm 1 debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel_input_status_confirm: type 100 id 0 X11 forwarding request failed on channel 0 debug2: channel_input_status_confirm: type 99 id 0 debug2: PTY allocation request accepted on channel 0 debug2: channel 0: rcvd adjust 2097152 debug2: channel_input_status_confirm: type 99 id 0 debug2: shell request accepted on channel 0 Last login: Tue Oct 9 16:36:16 2012 from 192.168.2.5 Have a lot of fun... Environment: LANG=de_DE.UTF-8 USER=karl LOGNAME=karl HOME=/home/karl PATH=/usr/bin:/bin:/usr/sbin:/sbin MAIL=/var/mail/karl SHELL=/bin/bash SSH_CLIENT=192.168.2.5 42364 1234 SSH_CONNECTION=192.168.2.5 42364 192.168.2.6 1234 SSH_TTY=/dev/pts/2 TERM=xterm XDG_SESSION_ID=33 XDG_RUNTIME_DIR=/run/user/karl ------------------------------------ Server-Seite---------------------------- /usr/sbin/sshd -D -d -p 1234 debug1: sshd version OpenSSH_6.0p1 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: read PEM private key done: type ECDSA debug1: private host key: #2 type 3 ECDSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-d' debug1: rexec_argv[3]='-p' debug1: rexec_argv[4]='1234' Set /proc/self/oom_score_adj from 0 to -1000 debug1: Bind to port 1234 on 0.0.0.0. Server listening on 0.0.0.0 port 1234. debug1: Bind to port 1234 on ::. Server listening on :: port 1234. debug1: Server will not fork when running in debugging mode. debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: inetd sockets after dupping: 3, 3 Connection from 192.168.2.5 port 42364 debug1: Client protocol version 2.0; client software version OpenSSH_6.0 debug1: match: OpenSSH_6.0 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.0 debug1: permanently_set_uid: 101/102 [preauth] debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug1: kex: client->server aes128-ctr hmac-md5 none [preauth] debug1: kex: server->client aes128-ctr hmac-md5 none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug1: KEX done [preauth] debug1: userauth-request for user karl service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug1: PAM: initializing for "karl" debug1: PAM: setting PAM_RHOST to "192.168.2.5" debug1: PAM: setting PAM_TTY to "ssh" debug1: userauth-request for user karl service ssh-connection method keyboard-interactive [preauth] debug1: attempt 1 failures 0 [preauth] debug1: keyboard-interactive devs [preauth] debug1: auth2_challenge: user=karl devs= [preauth] debug1: kbdint_alloc: devices 'pam' [preauth] debug1: auth2_challenge_start: trying authentication method 'pam' [preauth] Postponed keyboard-interactive for karl from 192.168.2.5 port 42364 ssh2 [preauth] debug1: do_pam_account: called debug1: PAM: num PAM env strings 0 Postponed keyboard-interactive/pam for karl from 192.168.2.5 port 42364 ssh2 [preauth] debug1: do_pam_account: called Accepted keyboard-interactive/pam for karl from 192.168.2.5 port 42364 ssh2 debug1: monitor_read_log: child log fd closed debug1: monitor_child_preauth: karl has been authenticated by privileged process debug1: PAM: establishing credentials User child is on pid 4091 debug1: SELinux support disabled debug1: PAM: establishing credentials debug1: permanently_set_uid: 1000/100 debug1: Entering interactive session for SSH2. debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions@openssh.com want_reply 0 debug1: server_input_channel_req: channel 0 request x11-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_new: session 0 debug1: SELinux support disabled debug1: session_pty_req: session 0 alloc /dev/pts/2 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: Setting controlling tty using TIOCSCTTY. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.2012 um 16:49 schrieb Karl Sinn <news@budostore.de>: Da ist der Fehler:
/usr/sbin/sshd -D -d -p 1234 [...] Failed to allocate internet-domain X11 display socket.
Tante Google meint, das könne an eingeschaltetem IPv6 liegen und man solle in die sshd_config ein beherztes "AddressFamily inet" einfügen (und den ssh-Server neustarren, natürlich) Rainer-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo,
Tante Google meint, das könne an eingeschaltetem IPv6 liegen und man solle in die sshd_config ein beherztes "AddressFamily inet" einfügen (und den ssh-Server neustarren, natürlich)
das war's, jetzt funktionierts, allerdings ist bei mir auf allen Rechnern IPV6 grundsätzlich ausgeschaltet... Vielen Dank Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 10/09/2012 04:49 PM, Karl Sinn wrote:
/usr/sbin/sshd -D -d -p 1234
Gib doch mal ein paar mehr -d mit, so ungefähr -ddd. ...
debug1: server_input_channel_req: channel 0 request x11-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed.
und achte dann darauf, was zwischen diesen Zeilen kommt. Vielleicht kann er ja einfach den Port 6010 oder so nicht öffnen. Eine andere Möglichkeit weiter zu forschen ist "strace -p $SSHD_PID -ff ...". So auf den ersten Blick denke ich, das Problem liegt auf dem Server. Torsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.2012 21:03, schrieb Torsten Förtsch:
On 10/09/2012 04:49 PM, Karl Sinn wrote:
/usr/sbin/sshd -D -d -p 1234 Gib doch mal ein paar mehr -d mit, so ungefähr -ddd.
...
debug1: server_input_channel_req: channel 0 request x11-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req x11-req Failed to allocate internet-domain X11 display socket. debug1: x11_create_display_inet failed. und achte dann darauf, was zwischen diesen Zeilen kommt.
Vielleicht kann er ja einfach den Port 6010 oder so nicht öffnen.
Eine andere Möglichkeit weiter zu forschen ist "strace -p $SSHD_PID -ff ...".
So auf den ersten Blick denke ich, das Problem liegt auf dem Server.
Torsten
Hallo Torsten, das Problem ist schon gelöst (siehe andere Nachricht) Vielen Dank Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo, beim Versuch das Problem zu lösen bin ich auf zwei weitere Probleme gestossen: - ich habe versucht eine Datei als su in ein anderes Verzeichnis zu kopieren und dort den Benutzer zu verändern. Das hat nicht funktioniert. Ist der Befehl chown über ssh gesperrt? - wenn ich über ssh versuche den Service neu zu stoppen mit service sshd stop passiert gar nichts. Ist auch das über ssh verboten? Wie macht man das? Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.2012 um 17:21 schrieb Karl Sinn <news@budostore.de>:
- ich habe versucht eine Datei als su in ein anderes Verzeichnis zu kopieren und dort den Benutzer zu verändern. Das hat nicht funktioniert. Ist der Befehl chown über ssh gesperrt?
Kann man machen, aber zeig' doch mal den Output von: cd /tmp sudo touch a ls -l a sudo chown nobody a ls -l a
- wenn ich über ssh versuche den Service neu zu stoppen mit service sshd stop passiert gar nichts. Ist auch das über ssh verboten?
Doch, da passiert schon was: der sshd arbeitet 2-teilig: Ein "Superprozess" mit root-Rechten, der dann einen geforkten Prozess mit den Rechten des verbindenden Users erzeugt. "service sshd restart" startet nur diesen "Superprozess" neu - Deine login-Session ist dadurch nicht betroffen, und alle Änderungen am sshd wirken sich erst beim nächsten Login (wenn nämlich ein neuer Prozeß erzeugt wird), aus. Rainer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hi, Am 09.10.2012 19:03, schrieb Rainer Sokoll:
Am 09.10.2012 um 17:21 schrieb Karl Sinn <news@budostore.de>:
- ich habe versucht eine Datei als su in ein anderes Verzeichnis zu kopieren und dort den Benutzer zu verändern. Das hat nicht funktioniert. Ist der Befehl chown über ssh gesperrt? Kann man machen, aber zeig' doch mal den Output von:
cd /tmp sudo touch a ls -l a sudo chown nobody a ls -l a
Jetzt klappt es, eventuell hing das mit dem anderen Problem zusammen.
- wenn ich über ssh versuche den Service neu zu stoppen mit service sshd stop passiert gar nichts. Ist auch das über ssh verboten? Doch, da passiert schon was: der sshd arbeitet 2-teilig: Ein "Superprozess" mit root-Rechten, der dann einen geforkten Prozess mit den Rechten des verbindenden Users erzeugt. "service sshd restart" startet nur diesen "Superprozess" neu - Deine login-Session ist dadurch nicht betroffen, und alle Änderungen am sshd wirken sich erst beim nächsten Login (wenn nämlich ein neuer Prozeß erzeugt wird), aus.
OK, verstehe, wenn ich also Einstellungen dazu mache, muss ich den sshd neu starten, und dann ausloggen und wieder einloggen, dann passt es wieder. Vielen Dank für Deine/Eure Hilfe Gruß Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 09.10.2012 um 19:32 schrieb Karl Sinn <news@budostore.de>:
OK, verstehe, wenn ich also Einstellungen dazu mache, muss ich den sshd neu starten, und dann ausloggen und wieder einloggen, dann passt es wieder.
Besser ist es, nach dem Neustart des sshd eine zweite ssh-session aufzumachen und die alte stehenzulassen. Denn es könnte ja sein, daß man etwas verkonfiguriert hat. Dann hat man immer noch die Chance, das in der ersten session zu beheben, Hättest Du Dich gleich ausgelogggt, kämest Du evtl. gar nicht mehr auf den Rechner, was vor allem dann wehtut, wenn der ein paar tausend Kilometer weg ist :-) Rainer -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Besser ist es, nach dem Neustart des sshd eine zweite ssh-session aufzumachen und die alte stehenzulassen. Denn es könnte ja sein, daß man etwas verkonfiguriert hat. Dann hat man immer noch die Chance, das in der ersten session zu beheben, Hättest Du Dich gleich ausgelogggt, kämest Du evtl. gar nicht mehr auf den Rechner, was vor allem dann wehtut, wenn der ein paar tausend Kilometer weg ist :-)
:D das wäre dumm... Danke Dir Karl -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (3)
-
Karl Sinn -
Rainer Sokoll -
Torsten Förtsch