SSH Verbindung ohne eine Passwortabfrage und X11

Warum das? Wer braucht das? Was ist der Nutzen?

Was will ich damit erreichen? Warum soll ich mich auf einem Rechner einloggen können, ohne diese Verbindung mit einem Passwort zu bestätigen? Ist das nicht viel zu gefährlich? Wer braucht das? All das sind so fragen, die man sich vorher stellt, aber das muß wirklich jeder welber wissen ob er das braucht und wozu er das brauchen könnte. Natürlich würde ich nicht den Benutzer "root" so einrichten, ich glaube das ist dann wie selbstmord. Auch würde ich das nicht mit einem Firmennetz machen, von dem aus jeder sich jeder mögliche Mitarbeiter auf den Rechner einloggen könnte und dort herumfuschen. Egal wie man es auffaßt, es ist einen Sicherheitslücke. Aber vielleicht hat einer von euch schon ganau so etwas gesucht, und wenn man dann auch noch einen X11 Stream aufbauen kann und somit auch X11 Anwendung laufen lassen kann, das ist noch ein extra Bonus oben drauf. Ich wünsche euch viel Spaß beim lesen meines Artikels.

1. Vorwort
2. Den Client Host konfigurieren
3. Den Remote Host konfigurieren
4. sudo hilft den remote Rechner herunterfahren
5. X11 Clients gesichert remote starten
6. CD/DVD-ROM's remote brennen

Ich wünsche euch viel Spaß beim lesen und ich hoffe, ich kann euch bei etwas behilflich sein oder euch eine neue Anregung mit auf dem Weg geben.

Vorwort

Ob Ihr das brauch oder nicht, ich glaube das muß jeder von euch selber wissen oder entscheiden. Ich möchte eucht nur ein mal ein paar Anregungen und ein paar Beispiele zeigen, wozu man das brauchen könnte. Wer meinen Artikel "Linux Server als Wireless LAN Access Point" gelesen hat der kann sich vielleicht noch daran erinnern, wie mein Netzwerk aufgebaut ist. Wenn nicht, ist auch egal, auf der Grafik sehen wir noch einmal mein Netzwerk im deteil.
Der Rechner "powerws", "testi", "leppi" und alle anderen Rechner, oh ja, das sind meine Kisten die alle möglichen zwecke erfüllen. Meiner Frau gehört der Rechner "schleppi", den auch meisten nur sie benutzt, meisten um das WWW zu durchforsten. Das Herzstück für diese Angelegenheiten ist der Rechner/Server "susi", der das Wireless LAN mit dem normalen LAN verbindet und beide Netzwerke wiederum in das Internet routet. An dem Server ist keine Tastatur, Maus und auch kein Monitor angeschlossen, somit ist es auch nicht möglich, den Server direkt zu bedienen oder geschweige denn auszuschalten, das muß alles über das Netzwerk passieren, was auch alles 100%'ig klappt. Jetzt will man seinen Anwender, die natürlich überhaupt keine Ahnung haben, was eine SSH Verbindung ist usw. da wird das herunterfahren des Server nach einer WWW surv Aktion schon komplizierter. Meine erste Lösung war mit hilfe von Webmin. Ich habe meiner Frau auf dem "susi" Server einen login mit dem gleichen Benutzernamen und Passwort wie sie auch im Linux System hat, eingerichtet. In Ihrem Browser haben ich Ihr ein Lesezeichen eingerichtet, der dann direkt auf die Seite von Webmin ging, wo man nur bestätigen mußte, ob der Server wirklich heruntergefahren werden soll oder nicht. Eine schönen und gute Lösung, aber es könnte doch etwas einfacher gehen. Was wirklich schön wär, ein Icon auf dem Desktop, der susi ausschalten heist und auf dem man nur ein mal mit der Maus klicken muß und der Server fährt sofort ohne viel Bla Bla und logins herunter. Ich habe mich in dieser Richtung versucht schlau zu machen und eine wirklich schöne Lösung mit Hilfe des SSH - Clients und einem öffentlichen Schlüssel der auf dem Server abgelegt wird. Somit ist es dann auch nur möglich, mit diesem Rechner, vom dem der öffentliche Schlüssen stammt auf dem Server ein Passwortlose Verbindung aufzubauen. Was wiederrum auch einen kleine Sicherheit ist. Für private kleine LAN's oder in kleinern Firmennetzwerken oder halt in Schulnetzwerken ist das einen wirklich schönen Lösung, mit der mach auch die Möglichkeit hat, anderen Programme zu starten und das sogar auch mit X11 - Clients. Aber liest doch weiter, und probiert das selber mal aus. Ich wünsche euch viel Spaß beim lesen, vielleicht kann ich euch ein bischen weiter helfen oder euch weitere Anregungen geben.

[Inhaltsverzeichnis]

Den Client Host konfigurieren

Damit man sich auf einen Rechner überhaupt ohne Passwort per SSH - Client einloggen kann, muß man als erste auf dem Rechner, der sich einloggen möchte, einen "public key" erstellen. Den "public key" (öffentlichen Schlüssel) braucht man, damit der Rechner vernünftig autenthifiziert werden kann, in meinem Beispiel ist das der Rechner "schleppi". Diesen Schlüssel kann man wie folgt erstellen:

benutzer@schleppi:~> ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/benutzer/.ssh/id_dsa): 

Hier wird man jetzt nach einem Dateinamen und den Pfard gefragt. Man kann eigentlich mit Return bestätigen, denn den Dateinamen werden wir später noch ändern. Hierfür wird der öffentliche Schlüssen auf den Rechner kopiert, auf den man sich ohne Passwort einloggen möchte, in meinem Beispiel wär das dann der remote Rechner "susi", doch dazu später.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/benutzer/.ssh/id_dsa.
Your public key has been saved in /home/benutzer/.ssh/id_dsa.pub.
The key fingerprint is:
87:d6:68:bb:61:3c:dc:91:b9:4c:f6:de:85:37:8d:ca benutzer@schleppi
benutzer@schleppi:~>

Bei der Frage nach dem passphrase, bestätigt man mit einem druck auf die Return-Taste. Danach muß man noch einmal bestätigen und man drückt am besten wiederholt auf die Return-Taste. Danach wir der Schlüssel generiert und es werden zwei Dateien erstellt.

benutzer@schleppi:~> cd .ssh
benutzer@schleppi:~/.ssh> ls
id_dsa  id_dsa.pub  known_hosts

Die Datei "known_hosts" könnte schon existieren wenn man sich schon einmal auf einen anderen Rechner per ssh eingelogt hat. Beim login auf einen entferneten Rechner, wird auch ein Schlüssel erstellt und in diese Datei geschrieben. Das akzeptieren des Schlüssels muß man beim einloggen auch mit einem "yes" bestätigen. Der Schlüssel wir dann auch in diese Datei geschrieben, somit ist beim zweiten login auf den Rechner der Schlüssel schon bekannt und muß nicht nocheinmal erstellt werden. In der Datei mit mit der Endung ".pub" befindet sich der "public key". Es ist auch die Datei, die auf den entfernten Rechner kopiert werden muß.

[Inhaltsverzeichnis]

Den Remote Host konfigurieren

Bevor wir jetzt den öffentlichen Schlüssel auf den enternten Rechner kopieren, sollte man sich von dem entfernten Rechner auch schon mal eine Verbindung zu dem Rechner aufgebaut haben, von dem man sich ohne Passwort einloggen will. Das geht natürlich auch am einfachsten mit SSH.

benutzer@schleppi:~/.ssh> ssh benutzer@susi
The authenticity of host 'susi (192.168.1.1)' can't be established.
RSA key fingerprint is 91:91:d4:a1:93:de:e8:3e:82:8b:c4:63:a2:e5:4d:31.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
Password: 
Last login: Tue Feb  8 20:47:22 2005 from 192.168.1.10
Have a lot of fun...
benutzer@susi:~>

Beim ersten Verbinden zu dem remote Host wir der Schlüssen für diesen Rechner angefordert bzw. erstellt und in der Datei "~/.ssh/known_hosts" abgelegt. Den Schlüssel muß man auch mit deim "yes" bestätigen, was auch ausgeschrieben wir (yes). Hat man dies getan, wird nach dem Benutzerpasswort gefragt dann ist man auf dem Rechner angemeldet als würde man vor diesem Rechner sitzen. Es kann durchaus sein, das dieser Benutzer auf dem Remoterechner sich noch nie auf einen anderen Rechner per ssh Verbunden hat, wenn dies der Fall ist, müßte man noch ein Verzeichnis und am besten eine Datei anlegen, aber das könne wir auch vom System selber machen lassen. Am besten man Verbindet sich wieder mit dem Rechner "schleppi", auf dem man auch den öffentlichen Schlüssel erstellt hat.

benutzer@susi:~> ssh benutzer@schleppi
The authenticity of host 'schleppi (192.168.2.10)' can't be established.
RSA key fingerprint is 87:d6:68:bb:61:3c:dc:91:b9:4c:f6:de:85:37:8d:ca.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.2.10' (RSA) to the list of known hosts.
Password: 
Last login: Tue Feb  8 19:40:20 2005 from 192.168.1.10
Have a lot of fun...
benutzer@schleppi:~>

Genau wie vorhin nur anderherum. Jetzt wurde auch auf dem entfernten Host das Verzeichnis "~/.ssh" mit der Datei "~/.ssh/known_hosts" angelegt in dem unser Rechner jetzt auch schon bekannt ist. Für unsere Passwortlose Verbindung ist die "~/.ssh/known_hosts" Datei zwar überhaupt nicht relevant, ist aber nicht schlecht wenn der Rechner dort bekannt ist. Jetzt muß man nur noch darauf achten, das man wieder auf seinem Rechner ist, auf dem man den öffentlichen Schlüssel erstellt hat, dann kann man mit dem folgenden Befehl das ganze aktivieren:

benutzer@schleppi:~/.ssh> scp id_dsa.pub benutzer@susi:~/.ssh/authorized_keys
Password: 
id_dsa.pub                                    100%  603     0.6KB/s   00:00    
benutzer@schleppi:~/.ssh>

Bei deisem Kopiervorgang erschlägt man eigentlich drei Fliegen mit einer Klappe. Man Verbindet sich einmal per ssh auf den gewünschten Rechner, die Datei wird und das passende Verzeichnis mit dem benötigten Namen kopiert. Denn die Datei darf auf dem entfernten Host nicht "id_dsa.pub" heisen, sie muß umbenannt werden und zwar in die Datei "authorized_keys". Man sollte aber schon darauf achten, das der Benutzer auf den lokalem Host und auf dem remote Host der selbe ist, so würde in unserem Beispiel der lokale Benutzer auch "benutzer" lauten. So, jetzt ist es geschaft, der erste Verbindungsaufbau ohne Passwort kann getestet werden.

benutzer@schleppi:~/.ssh> ssh benutzer@susi
Last login: Tue Feb  8 21:17:50 2005 from 192.168.2.10
Have a lot of fun...
benutzer@susi:~>

Saust die Anmeldungsprozedur durch ohne anzuhalten, dann hat man es geschaft. Aber bitte beachtet, die Verbindung ist einseitig. Wenn man eine Verbindung von dem entfernten Host aufbauen möchte, wird man selbstverständlich weiterhin nach einem Passwort gefragt. Wenn das auch gewünscht ist, muß man den Weg einfach umdrechen, den öffentlichen Schlüssel auf dem entfernten Rechner erstellen und auf dem lokalen Rechner kopieren.

[Inhaltsverzeichnis]

sudo hilft den remote Rechner herunterfahren

Ein Anwendungsbeispiel kann es sein, den remote Rechner mit der Hilfe von "sudo" herunterfahren zu lassen. Dazu Verbindet man sich mit dem entfernten Rechner mit "root" Rechten. am einfachsten geht das wohl mit dem Befehl "ssh root@susi" oder wenn man schon als normaler Benutzer mit diesem Rechner verbunden ist mit "su" und gibt dann als Benutzer root den Befehl "visudo" ein und es öffnet sich der vi Editor mit den aktuellen "sudoers Tabelle" für diesen Rechner. Dort kann man am Ende der Datei die folgenden Zeilen einfügen:

benutzer    ALL=(ALL)     NOPASSWD:/sbin/halt
benutzer    ALL=(ALL)     NOPASSWD:/sbin/reboot
benutzer    ALL=(ALL)     NOPASSWD:/etc/init.d/apache
benutzer    ALL=(ALL)     NOPASSWD:/sbin/lspci

Wenn man noch andere Programme braucht, diese kann man dann auch auf dem gleichen Wege einpflegen, wie ich das mit dem Start-/Stoppscript für den Apache2 Webserver und auch bei dem Programm "lspci" gemacht habe. Bei anderen Programmen oder Scripts sieht die Syntax dann genau so aus. Und wie sieht das aus? Als erstes logt man sich als "root" von dem entfernten Rechner wieder aus. Da ich davon ausgehe, das die Passwortlose Verbindung zu dem entfernten Rechner funktioniert, dann kann man gleich den großen Test starte. Man muß wieder am lokalen Rechner, in unserem Fall war das ja der Rechner "schleppi" als normaler Benutzer angebeldet sein. Jetzt können wir einen ersten Test wagen. Dafür geben wir auf unserem Rechner dem Befehl "ssh -A -4 benutzer@susi sudo /sbin/lspci" eingeben, dann sollte der Rechner einer Verbindung zu dem entgernten Rechner "susi" aufbauen, das Programm "sudo" aufrufen, welches wiederrum das Programm "/sbin/lspci" aufruft und alle an das PCI Bussysten angeschlossenen Geräte anzeigt. Aussehen könnte die Ausgabeliste dann wie folgt:

benutzer@schleppi:~> ssh -A -4 benutzer@susi sudo /sbin/lspci
0000:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
0000:00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
0000:00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
0000:00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
0000:00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
0000:00:08.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01)
0000:00:0a.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 43)
0000:00:0b.0 SCSI storage controller: Adaptec AHA-2940U2/U2W

Nachdem das programm ausgeführt wurde, trennt SSH auch die Verbundung zu unserem entfernten Rechner. Ist doch perfekt, oder nicht. Wenn das alles geklappt hat, kann man das ganze mit einem "reboot" des entfernten Rechner ausprobieren, allesdings sollte man sich zuvor davon vergewissern, gearde kein anderen auf oder mit dem entfernten Rechner arbeitet. Wenn das nicht der Fall ist, dann sollte man mit dem Befehl "ssh -A -4 benutzer@susi sudo /sbin/reboot" den entfernten Rechner neustarten können. Wenn der Rechner jetzt einmal piept und daraufhin neustartet, hat man es geschaft.

Sollte das nicht geklappt haben, dann empfehle ich, das man als erstes noch einmal überprüft, das mit dem Passwortlosen Verbinden auch klappt. Als nächstes sollte man auf den entfernten Rechner als Benutzer "root" noch einmal die "visudo" Tabellen überprüfen, ob die wie oben eingetragen ist. Dann sollte man beim ausführen des "sudo" Behehles darauf dachten, das auch der ganze Pfad des Befehls/Scripts eingetippt ist, da es ansers nicht klappt.
Nicht Richtig ist: ssh -A -4 benutzer@susi sudo reboot
Richtig ist: ssh -A -4 benutzer@susi sudo /sbin/reboot
So wie man das auch in seiner "visudo" Tabelle eingetragen hat. Das ist eine sehr beliebte Falle, in die ich auch schon getappt bin. Probiert es noch einmal aus, wenn es dann immer noch nicht klappen sollte, dann schaut euch alle Einstellungen noch einmal an oder probiert es nocheinmal von Anfang an. Bestimmt hat sich wo ein kleiner Tippfehler eingeschlichen.

[Inhaltsverzeichnis]

X11 Clients gesichert remote starten

Was in unserem Anwendungsbeispiel mit dem Shell Programmen/Scripts funktioniert, das klappt auch mit X11 Clients. Mit zusätzlichen Parametern kann mein auch über eine SSH Verbindung einen X Stream ausführen, somit kann man fast jedes beliebiges X11 Programm/Script remote starten, das Fenster öffnet sich aber auf den eigenen Desktop. Das ging zwar unter Linux und X11 schon immer, war aber recht aufwendig und vor allem sehr unsicher. Dadurch das wir uns schon sowieso ohne Passwort mit dem Rechner verbinden, spielt die Sicherheit für uns nicht die wesentliche Rolle, ich wollte es nur einmal erwähnen, das mit SSH und einem X Stream die komplette Verbindung verschlüsselt ist. Für uns spiel nur die einfache Handhabung einen Rolle, denn wenn wir uns eh ohne Passwort auf dem entfernten Rechner einlogen, dann könnten wir ja auch auf einen Button klick eine Anwendung auf dem remote Rechner starten.

benutzer@schleppi:~> ssh -X -A -Y -4 benutzer@susi /usr/X11/bin/xcalc

Dieser Befehl sollen dann auch das X11 Programm "xcalc" öffnen, auf dem eigenen Rechner. Das Programm sieht man zwar und man kann es benutzen, doch ausgeführt wird das Programm auf dem entfernten Rechner, in unserem Beispiel der Rechner "susi". Beendet den Taschenrechner, dann wird auch wie in unserem vorherigen Beispielen, automatisch die Verbindung getrennt. Wenn man mag, dann kann man sich jetzt auch noch einen Icon basteln, am besten unter KDE oder GNOME, dort den Befehl wie oben eintragen und "remote xclac" benennen. Daraufhin sollte nach einem klick auf dem Icon unser kleiner Taschenrechner von vorhin auftauschen. Das sollte auch klappen.

Klappt es nicht, dann kann ich nur noch einmal raten, die Syntax zu überprüfen. Auch bei diesen Auffrufen muß man den kompletten Pfad eingeben, denn sonst startet auch das X Programm nicht. Was auch nicht vergessen werden darf, ist die "-X" Option. Denn diese ermöglicht es erst, einen X Stream aufzubauen. Die anderen Optionen kann man in der Hilfe (man ssh) nachlesen. Die Optionen "-A -Y" die habe ich mir so mit der Zeit angewöhnt. Zwingend brauchen tut man die nicht, aber ich hatte mal 2 oder 3 Programme (Wenn ich mich richtig erinnere, waren das alles X11 Programme), die nicht richtig starteten oder mit Error Fehlermeldungen abgebrochen sind. Mit Hilfe dieser beiden Optionen habe ich dieses Problemchen damals lösen können und deswegen habe ich mir diese auch angewöhnt.

[Inhaltsverzeichnis]

CD/DVD-ROM's remote brennen

Dieses Anwendungsbeispiel erkläre ich aber nur in der theorie. Die Praxis grundlagen mit diesem Artikel geliefert. Das ausdehnen auf die vielen möglichen Anwendungen ist dann jeder Manns eigene Sache und außerdem ist das dann auch nichts anderes mehr, als das bedienen eines Programms, welches auf einen entfernten Rechnes ausgeführt wird.

Eine Situation:

Eine Lösung:

Wozu ihr das gebrauchen könnt, das bleint jedem selber überlassen. Ich will nur noch einmal erwähnen, das ihr euer System damit sehr unsicher macht. Ob Ihr damit leben könnt, das muß auch jeder für sich selber entscheiden. Ich hoffe, das euch mein kleiner Artikel bei der Umsätzung geholfen hat und das euch dieser weiterhelfen konnte. Dann bin ich auch zufrieden. Wenn noch was ist, schreibt mir doch einfach eine E-Mail.

[Inhaltsverzeichnis]