Fernwartung..VNC...krdp...xfreerdp zuerst nur lokales Netz ...

Gerschon · 23. Januar 2014

Hi großes thx...

Das war es wohl mit Block von der Firewall.
Jetzt gehen die Verbindungen jeweils abwechselnd von einem Rechner zum anderen.

Hier mal der Ausdruck von Rechner 2:

Code

systemctl status sshd.service
sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Thu 2014-01-23 18:57:20 CET; 2h 37min ago
  Process: 3458 ExecStartPre=/usr/sbin/sshd-gen-keys-start (code=exited, status=0/SUCCESS)
 Main PID: 3460 (sshd)
   CGroup: /system.slice/sshd.service
       	└─3460 /usr/sbin/sshd -D


Jan 23 21:26:14 nepi sshd[4273]: Accepted keyboard-interactive/pam for robert from 192.168.20.50 port 50931 ssh2
Jan 23 21:26:14 nepi sshd[4273]: pam_unix(sshd:session): session opened for user robert by (uid=0)
Jan 23 21:31:10 nepi sshd[4341]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=nepi user=robert
Jan 23 21:31:12 nepi sshd[4339]: error: PAM: Authentication failure for robert from nepi
Jan 23 21:31:13 nepi sshd[4342]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=nepi  user=robert
Jan 23 21:31:16 nepi sshd[4339]: error: PAM: Authentication failure for robert from nepi
Jan 23 21:31:31 nepi sshd[4339]: Accepted keyboard-interactive/pam for robert from 192.168.20.90 port 42421 ssh2
Jan 23 21:31:31 nepi sshd[4339]: pam_unix(sshd:session): session opened for user robert by (uid=0)
Jan 23 21:32:11 nepi sshd[4386]: Accepted keyboard-interactive/pam for robert from 192.168.20.90 port 42422 ssh2
Jan 23 21:32:11 nepi sshd[4386]: pam_unix(sshd:session): session opened for user robert by (uid=0)

Alles anzeigen

Es kommt nur noch die Fehlermeldung Tunnel device open faied
Could not request tunnel forwarding
Damit auch kein X11.

Dann noch das mit PAM;...
Ich setzte mal jeweils auf beiden Rechnern (gleiche Fehleranzeige) in sshd_config den Parameter UsePAM yes auf no

Sauerland · 23. Januar 2014

Versuch es einmal mit xephir:
http://www.forum-raspberrypi.d…f-unix-linux-mac-systemen

Zitat
Anzeigen des Desktops in einem Fenster

In der zuvor beschriebenen Methode habe ich den remote-Desktop auf dem ganzen Bildschirm und umschalten muss ich mit STRG ALT Fn. Das ist nicht immer praktisch.
Und wenn ich einen Monitor mit großer Auflösung habe auch nicht notwendig (was soll der Pi mit 2560x1440 schon machen?).
Wenn man zwei Monitore betreibt, läuft der X-Server zuerst nur mit der kleineren Auflösung der beiden Monitore und der Desktop ist gespiegelt auf beiden
Monitoren.
Natürlich kann man sich jetzt hinsetzen und eine Konfigurationsdatei für den zweiten X-Server erstellen. Dies ist aber aufwändig und imho nicht notwendig. Denn es gibt eine weitere Lösung: den geschachtelten X-Server, mit dem ich einen remote-Desktop in einem Fenster laufen lassen kann.

Hierfür gibt es zwei Programme: Xnest und Xephyr. Letztere ist der Neuere und die Beschreibung bezieht sich auf ihn.
Zuerst muss ich Xephyr lokal installieren.

z.B. Debian
Code
apt-get install xserver-xephyr
z.B. OpenSuse
Code
zypper install xorg-x11-server-extra
Gib es auch für Mac OSX

Jetzt kann man z.B. folgende Befehle in einem Terminal ausführen (root-Rechte nicht notwendig):
Code
Xephyr :1 -screen 1200x1200 -dpi 96 -keybd ephyr,,,,xkblayout=de & DISPLAY=:1 ssh -X username@remote-machine lxsession &
Zunächst erscheint ein Fenster, dass 1200x1200 Pixel groß ist (plus Umrandung und Menüleiste).
Mit dem zweiten Befehl erscheint in diesem Fenster der Desktop des remote Rechners.

Der Aufruf von Xephyr sieht erstmal furchtbar aus. Im Einzelnen:

Da der laufende X-Server die Nummer :0 hat, muss der Neue die :1 bekommen (der nächste dann :2)
-screen 1200x1200 ist selbsterklärend. Es lassen sich beliebige Auflösungen angeben, muss natürlich zum eigenen Monitor passen.
-dpi 96 sollte sein, da Xephyr die Monitordaten nicht abfragen kann. Ohne diese Angabe ist u.U. die Schrift zu klein. Ausprobieren, welche Auflösung am besten passt. Sie muss nicht identisch mit der Auflösung des eigenen Monitors sein.
-keybd sollte sein, das sonst die Tastaturbelegung englisch ist. Die Mühe herauszubekommen, was die einzelnen Parameter der Option bedeuten, habe ich mir nicht mehr gemacht. Wer Spass daran hat, ...

Der nächste Befehl ist der Aufruf des Desktop auf dem remote-Rechner:

Mit DISPLAY=1 weise ich die Ausgabe des folgenden Befehls den X-Server :1 zu, also den zuvor aufgerufenen Xephyr.
Der ssh-Befehl ruft auf dem remote-Rechner das Programm lxsession auf, also den Desktop, der dann im Fenster erscheint.

Das Ganze ist jetzt auch verschlüsselt, da es über ssh läuft.

Schön ist auch: Bei dieser Lösung braucht lediglich das X11Forwarding erlaubt sein.
/etc/lightdm/lightdm.conf muss nicht angepasst werden. Genauso wenig muss der Dienst lightdm laufen.

Aber aufgepasst!
Der remote-Desktop läuft in einem Fenster. Schliesse ich es, dann ist auch der Inhalt weg. Pech gehabt, wenn da etwas nicht gespeichert ist.

Viel Spaß
Alles anzeigen

Dazu allerdings gesagt:
Bitte nur in Deinem internen Netz, nicht im Internet.

Gerschon · 26. Januar 2014

Habe leider doch noch Probleme mit dem ssh.

Ich habe das vorgeschlagene Terminalfenster auf beiden Rechnern installiert.

Davor hatte ich noch mal neu die keys auf Rechner 1 generiert mit ssh-keygen -t rsa -b 4096.
(Die vorhergehenden is_rsh. id_rsh.pub hatte ich aus dem Verzeichnis /root/.ssh gelöscht).

Es soll ja so sein, das nur die id_rsh.pub im Verzeichnis .ssh bleiben. Also habe ich id_pub auf Rechner 1 gelassen. id_rsh auf ein Verzeichnis auf den Memorystick mit rootterminal kopiert und auch id_rsa.pub für den Rechner 2 (als ssh -server). dazu mit rm id_rsa auf Rechner 1 den persönlichen Schlüssel gelöscht.

Vom Memorystick habe ich dann die id_rsa.pub auf Rechner 2 kopiert.
Nach sshd stop...start.. status den Dämondienst neu gestartet.

Nun bekomme ich aber beim Start vvon Rechner 1 (Rechner 2 also ssh-Server) folgende Meldung:

[cs]ssh robert@nepi
Permission denied (publickey,password,keyboard-interactive).
[/cs]

Umgekehrt von Rechner 2 auf Rechner 1 (Rechner 1 in diesem Fall der Server ist die Meldung auch:

[cs]Permission denied (publickey,password,keyboard-interactive).
[/cs][/cs]

Es soll ja so sein, dass der private Schlüssel auf dem Memorystick ist und nur der öffentliche Schlüssel auf dem jeweiligen ssh-Server.

Bei Bedarf kann ich dann vom Memorystick die Datei id_ssh.pub über den Pfad (einmal Memorypfad aufgerufen und da stehend) mit cp id_rsa.pub /root/.ssh kopieren.

Mit scp-Befehl nach der Vorlage SSH Spickzettel komme ich nicht klar.

Firewall ist offen ... geprüft.

Was ist denn da falsch gelaufen? Oder muss ich da noch was anderes einstellen?

Sauerland · 26. Januar 2014

Zitat von Gerschon

Habe leider doch noch Probleme mit dem ssh.

Ich habe das vorgeschlagene Terminalfenster auf beiden Rechnern installiert.

Davor hatte ich noch mal neu die keys auf Rechner 1 generiert mit ssh-keygen -t rsa -b 4096.
(Die vorhergehenden is_rsh. id_rsh.pub hatte ich aus dem Verzeichnis /root/.ssh gelöscht).

Es soll ja so sein, das nur die id_rsh.pub im Verzeichnis .ssh bleiben. Also habe ich id_pub auf Rechner 1 gelassen. id_rsh auf ein Verzeichnis auf den Memorystick mit rootterminal kopiert und auch id_rsa.pub für den Rechner 2 (als ssh -server). dazu mit rm id_rsa auf Rechner 1 den persönlichen Schlüssel gelöscht.

Vom Memorystick habe ich dann die id_rsa.pub auf Rechner 2 kopiert.
Nach sshd stop...start.. status den Dämondienst neu gestartet.

Alles anzeigen

Warum arbeitest Du in /root/.ssh?

Benutze ssh als User und wechsle erst nach der Anmeldung mit su zu root.
Daher braucht auch nur Dein User einen Schlüssel.

Die Befehle zum Erstellen und verschieben von ssh-keys sind:

Code

ssh-keygen

Code

ssh-copy-id

Abgelegt werden die öffentlichen Schlüssel auf dem Server unter /home/Benutzername/.ssh/authorized_keys.
Der öffentliche Schlüssel wird auf dem Client unter /home/Benutzername/.ssh/id-rsa gespeichert und kann mit ssh-copy-id direkt verschoben werden.

Außerdem würde ich dazu raten, erst einmal einen Client und einen Server miteinander zu verbinden, bevor es dann in die andere Richtung geht, wobei ich da allerdings nicht verstehe, warum.

Gerschon · 29. Januar 2014

Hast ja Recht nur im normalen Teminal (nicht Rootterminal) ssh Verbindungen im lokalen Netzwerk.

Habe es wieder hin bekommen, allerdings sind da noch kleine Fehler drinne.

Hier der Fehlerausdruck von Client (Rechner 2) zu Server (Rechner 1).

Code

ssh robert@maxi
Host key fingerprint is 76:09:d7:1d:d3:a1:26:a6:79:b7:c3:43:b6:83:fb:51
+--[ECDSA  256]---+
|          	oo.|
|       	. ..o.|
|    	. .o.o.  |
|     	o+.o	|
|    	Soo. + E |
|   	. .. * +  |
|       	. O   |
|        	. =  |
|       	...   |
+-----------------+


Password: 
Tunnel device open failed.
Could not request tunnel forwarding.
X11 forwarding request failed on channel 0

Alles anzeigen

VPN Tunneling will ich noch später machen.
Aber mit X11 geht es leider auch noch nicht.

Hier mit Grafikprogramm Xephir...

Code

Xephyr :1 -screen 1200x1200 -dpi 96 -keybd ephyr,,,,xkblayout=de & DISPLAY=:1 ssh -X robert@maxi lxsession &
[1] 2850
[2] 2851
robert@nepi:~> Host key fingerprint is 76:09:d7:1d:d3:a1:26:a6:79:b7:c3:43:b6:83:fb:51
+--[ECDSA  256]---+
|          	oo.|
|       	. ..o.|
|    	. .o.o.  |
|     	o+.o	|
|    	Soo. + E |
|   	. .. * +  |
|       	. O   |
|        	. =  |
|       	...   |
+-----------------+


Initializing built-in extension Generic Event Extension
Initializing built-in extension SHAPE
Initializing built-in extension MIT-SHM
Initializing built-in extension XInputExtension
Initializing built-in extension XTEST
Initializing built-in extension BIG-REQUESTS
Initializing built-in extension SYNC
Initializing built-in extension XKEYBOARD
Initializing built-in extension XC-MISC
Initializing built-in extension SECURITY
Initializing built-in extension XINERAMA
Initializing built-in extension XFIXES
Initializing built-in extension RENDER
Initializing built-in extension RANDR
Initializing built-in extension COMPOSITE
Initializing built-in extension DAMAGE
Initializing built-in extension MIT-SCREEN-SAVER
Initializing built-in extension DOUBLE-BUFFER
Initializing built-in extension RECORD
Initializing built-in extension DPMS
Initializing built-in extension X-Resource
Initializing built-in extension XVideo
Initializing built-in extension XVideo-MotionCompensation
[dix] Could not init font path element /usr/share/fonts/misc/sgi:unscaled, removing from list!
Kbd option key () of value ((null)) not assigned!                                                                                                                                                                                        	
The XKEYBOARD keymap compiler (xkbcomp) reports:                                                                                                                                                                                         	
> Warning:      	Type "ONE_LEVEL" has 1 levels, but <RALT> has 2 symbols                                                                                                                                                              	
>               	Ignoring extra symbols                                                                                                                                                                                               	
Errors from xkbcomp are not fatal to the X server                                                                                                                                                                                        	
Lost connection to X server: Resource temporarily unavailable                                                                                                                                                                            	
Xephyr :1 -screen
exit

Alles anzeigen

Was könnte da sein? X11 kommt, aber ohne systempromt.

Fernwartung..VNC...krdp...xfreerdp zuerst nur lokales Netz ...

First Adobe, Now Autodesk? SolidCraft Wants to Replace Fusion

Tumbleweed-Update bricht ab

GNOME OS Preview: Ein Schritt in Richtung Alltagsbetrieb

Ubuntu 26.10 „Stonking Stingray“ ist erschienen

KDE Plasma 6.8 verabschiedet sich von X11

pit1958ffm

Wanderratte

k.113

aitexturegenerator

Giorgio68

Teilen