• netzwerk
  • sshd
  • vnc
  • ajaxterm
  • vpn
• linux
• windows

ssh $USER@$SSH-Server

Will man auf einem entfernten Server nicht immer das Passwort eingeben oder sollen Skripts vollautomatisch verschlüsselte Verbindungen aufbauen, braucht man als Client Zertifikate.

Diese kann man unter Unix/Linux mit folgendem Befehl generieren lassen:

(client) $ ssh-keygen -t rsa -b 8192
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
ee:ab:c2:93:9a:9d:31:df:aa:09:87:12:29:5a:f8:21 user@client
The key's randomart image is:
+--[ RSA 8192]----+
|         .0ooo   |
|          0..    |
|           -     |
|         . - .   |
|   .:::.L        |
|       :.oo.: A  |
|         VV      |
|          \\     |
|           `^::_.|
+-----------------+
(client) $ 

Hier werden zwei Dateien erstellt:

• ~/.ssh/id_rsa ← Private-Key ⇒ niemals irgendjemandem geben
• ~/.ssh/id_rsa.pub ← Public-Key ⇒ den kannst du jedem geben, diese Datei musst du auch auf deine Zielsysteme kopieren.

Um die Technologie nutzen zu können, muss der Public-Key auf den Zielsystemen der Datei '~/.ssh/authorized_keys' angehänt werden:

$ cat ~/.ssh/id_rsa.pub | ssh ${USER}@${HOST} "mkdir -p --mode=700 ~/.ssh; tee >> ~/.ssh/authorized_keys"

Der Verlauf könnte so aussehen:

(client) $ cat ~/.ssh/id_rsa.pub | ssh benutzer@root_server "mkdir -p --mode=700 ~/.ssh; tee >> ~/.ssh/authorized_keys" 
# Banner
Password:
# MotD...

Closing connection...

(client) $

Jetzt kann man entweder mit dem Passwort auf dem Server einloggen oder mit dem Zertifikat, welches unter Umständen auch noch ein Passwort hat.

(client) $ ssh ${USER}@${HOST}
# Banner
# MotD...
(server) $ 

1. Wer den Private-Key, also die Datei '~/.ssh/is.rsa' in die Finger bekommt und kein oder ein schwaches Passwort darauf liegt, kann sich diese Person auf allen Systemen ohne Rückfrage einloggen und dort wüten.
2. Wenn der Server das Einloggen mit nicht erlaubt, geht es nicht. Der Server-Admin muss diese Option aktivieren: sshd

• http://sial.org/howto/openssh/publickey-auth/

SSH erlaubt es auch Daten auszutauschen. Das Protokoll wird üblicherweise sftp genannt.

Auf Konsolenebene gibt es das Programm 'sftp'
Benutzung: $ sftp $USER@SSH-Server
Tipp: vorher in das Arbeitsverzeichniss wechseln.

Wer Gnome einsetzt kann Nautilus bequem einsetzten:

Windows unerstützt das Protokoll selbst nicht, dem kann aber mit Filezilla abgeholfen werden:

http://sourceforge.net/projects/filezilla/

SSH eröffnet uns die Möglichkeit, einen Socksproxy, für die sichere Übertragung zwischen Client und Server, zu emulieren. Wir müssen legedich den Port auf dem Client angeben.

ssh -D $SOCKSPort $SSH-Server

Da SSH zu den TCP-Protokollen gehört, können auch nur TCP-Protokolle getunnelt werden. Was das getunnelte Protokoll schlussendlich überträgt, ist SSH egal. Es funktioniert in diesem Fall wie ein Netzwerk-Switch. Dieser leitet, wie in diesem Fall SSH, die Daten auch 'nur' weiter.

Zugriff auf ein entferntes System im Netz des Servers

ssh  -L [lokale_ip:]lokaler_port:remote_ip:remote_port proxy_user@proxy_host

Zugriff vom entfernten System auf eine im lokalen Netz

ssh  -R [entfernte_ip:]entfernter_port:lokale_ip:lokaler_port proxy_user@proxy_host

Vom Client 'localhost:1322' nach '192.168.0.12:80' via den Server '192.168.0.12' mit dem Benutzer 'hans'

$ ssh -L 1322:192.168.0.12:80 hans@192.168.0.13

Möchte man anderen die Verbingung auch erlauben sollte man 'root' sein und folgenden Befehl ausführen:

# ssh -L *:1322:192.168.0.12:80 hans@192.168.0.13

Hat das lokale Gerät mehrere IP's, ist es eine gute Idee den Stern duch die gewünschte IP zu ersetzten, da sonst eventuell zuviele Leute zugriff haben könnten.

Einen lokalen Dienst im anderen Netz anbieten kann man so:

$ ssh -R *:80:127.0.0.1:80 hans@192.168.0.13

Dafür sind aber Rechte erforderlich, es ist darum eine gute Idee sich als 'root' am entfernten System anzumelden.

SSH erlaubt uns auch ein X-Fenster weiterzuleiten. Das heisst, wir müssen das Programm auf dem Client nicht installiet haben. Der Befehl lautet normalerweise so:

ssh -x $SSH-Server

Da ich aber feststellen musste, dass dies oft nicht funktionierte, kommmt hier der zweite Befehl:

ssh -x -Y $SSH-Server

1. Unter Ubuntu 7.10 wurde zwar das Prgramm vom Server geholt, es verwendete aber die lokalen Dateien.
   • Vermutung: Das passierte weil das Programm bereits schon lokal gelaufen ist.
2. Ein Fenster über das Internet zu übertragen funktioniert. Server und Client brauchen aber eine schnelle Verbindung. Zudem löst jeder Verschiebung der Maus über dem Fenster einen Request aus, was wieder Traffic verursacht.

http://sourceforge.net/projects/xming/

Es werden nur die Pakete 'Xming' und Xming-fonts' benötigt. Zuerst Xming installieren und dann Xming-fonts in das gleich Verzeichnis installieren (Fehlermeldung ignorieren). Danach kann eine Verbindung mit dem XLaunch-Programm gestartet werden.

Weiter Infos: http://wiki.ubuntuusers.de/Xming

Will man einem anderen Benutzer auf einem anderen Gerät ein Fenster schicken, muss man im X-Server berechtigt sein, denn man ist lokal ein Client, welcher sich beim Server (PC des Benutzers) anmelden will.

Mit dem Programm 'xhost' kann man temporäre Berechtigungen auf dem X-Server vergeben. Als Argument(e) kommen unter anderem folgende Möglichkeiten zum Zug:

• IPv4-/IPv6-Adresse
• DNS-Name
• Leer-String

Will man auf einem System alle ankommentden Verbindungen erlauben:

$ xhost +

Dies ist allerdings sehr unsicher, da ein X-Programm auch Zugriff auf die Zwischenablage erhält und nicht zwingend ein Fenster anzeigen muss.