SSH: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
(Eine Menge hinzugefügt) |
||
Zeile 1: | Zeile 1: | ||
= Secure SHell = | = Secure SHell = | ||
Mittels SSH kann man sich von einem beliebigen Rechner auf einen anderen Rechner anmelden, z.B. auf das Informatik-Rechenzentrum mit dem Informatik-Account. Das ist nützlich, wenn man z.B. von zu Hause auf Programme und Dateien zugreifen möchte, die auf den Informatik-Rechnern liegen, oder wenn man nicht von einem Poolrechner, sondern von einem beliebigen Rechner [[drucken]] möchte. Wie SSH beim iRZ und vielen anderen Instituten funktioniert, und was man damit alles tolles machen kann, ist in diesem Artikel beschrieben. | |||
=== hosts === | === hosts === | ||
Siehe [[#Infrastruktur_der_Institute_.2F_Fachbereiche|Infrastruktur der Institute / Fachbereiche]] | Siehe [[#Infrastruktur_der_Institute_.2F_Fachbereiche|Infrastruktur der Institute / Fachbereiche]] | ||
=== Simples Einloggen === | |||
Mit folgendem Befehl kann man sich auf seinem iRZ-Account einfach einloggen: | Mit folgendem Befehl kann man sich auf seinem iRZ-Account einfach einloggen: | ||
<pre> | <pre> | ||
$ ssh <kennung>@rzssh1.informatik.uni-hamburg.de | $ ssh <kennung>@rzssh1.informatik.uni-hamburg.de | ||
</pre> | </pre> | ||
Um sich die nervige Tipparbeit und das Eingeben des Passworts sparen zu können, werden im Weiteren ein paar Tricks erläutert. | |||
=== Konfiguration === | |||
Die ~/.ssh/config enthaelt die Konfiguration fuer deinen SSH Client. Dort kann man viele tolle Sachen machen, zB muss man nicht immer <code>ssh rzssh1.informatik.uni-hamburg.de</code> machen, sondern bspw. <code>ssh fbi</code>. Das ist gut. | Die ~/.ssh/config enthaelt die Konfiguration fuer deinen SSH Client. Dort kann man viele tolle Sachen machen, zB muss man nicht immer <code>ssh rzssh1.informatik.uni-hamburg.de</code> machen, sondern bspw. <code>ssh fbi</code>. Das ist gut. | ||
Zeile 23: | Zeile 18: | ||
<pre> | <pre> | ||
Host fbi | Host fbi | ||
User | User 9nachnam | ||
HostName rzssh1.informatik.uni-hamburg.de | |||
</pre> | |||
=== Parameter / Konfigurationseinträge === | |||
Man kann bei SSH viele nützliche Parameter übergeben, allerdings die meisten (oder alle?) auch einfach in der ~/.ssh/config eintragen. | |||
Wenn du in dieser Liste nicht fündig wirst und noch mehr tolle Sachen mit deiner SSH-Config-Datei machen willst, schau dir <pre>man ssh_config</pre> an. | |||
=== Arbeiten mit Wildcards === | |||
In der SSH-Config können z.B. in den Hostnames Wildcards vorkommen. Dadurch ist z.B. so ein Setup möglich: | |||
<pre> | |||
Host fbi* | |||
User 0bock | |||
[Viele weitere Einträge] | |||
Host fbi1 | |||
HostName rzssh1.informatik.uni-hamburg.de | |||
Host fbi2 | |||
Hostname rzssh2.informatik.uni-hamburg.de | |||
Host fbi | |||
HostName rzssh1.informatik.uni-hamburg.de | |||
</pre> | |||
Wenn man viele Konfigurationseinträge hat, kann man die durch eine Wildcard sowohl auf rzssh1 als auch rzssh2 (falls rzssh1 mal down ist) anwenden, und gleichzeitig immer noch den komfortablen alias fbi dazu haben. | |||
Bei manchen Parametern kann es auch sinnvoll sein, sie mittels | |||
<pre> | |||
Host * | |||
[Viele Einträge] | |||
</pre> | |||
auf alle Hosts anzuwenden. | |||
==== X-Forwarding ==== | |||
Wenn du grafische Anwendungen per SSH auf einem entfernten Host ausführen willst, so dass sie auf deinem lokalen Bildschirm angezeigt werden, kannst du SSH-Forwarding verwenden. Das geht mittels ForwardX11 in der ~/.ssh/config | |||
<pre> | |||
Host fbi | |||
User 0bock | |||
HostName rzssh1.informatik.uni-hamburg.de | |||
ForwardX11 yes | ForwardX11 yes | ||
</pre> | |||
oder per Parameter | |||
<pre> | |||
$ ssh -X <host> | |||
</pre> | |||
Es gibt auch ForwardX11Trusted bzw. den Parameter -Y. | |||
Falls die Performance von X-Forwarding schlecht ist, kann man versuchen, [[#Kompression|Kompression]] anzuschalten. | |||
Wenn die Performance immer noch zu schlecht ist, kann man statt direktem SSH mit X-Forwarding auch die Software X2GO ausprobieren, welche meistens eine bessere Performance hat, wofür allerdings aus dem Host der X2GO-Server installiert sein muss, wie das z.B. beim [[#DKRZ|DKRZ]] der Fall ist. | |||
==== DynamicForward ==== | |||
Um einen lokalen SOCKS-Proxy zum [[Tunneln]] einzurichten, kannst du DynamicForward verwenden: | |||
<pre> | |||
Host fbi | |||
User 0bock | |||
HostName rzssh1.informatik.uni-hamburg.de | HostName rzssh1.informatik.uni-hamburg.de | ||
DynamicForward 7777 | DynamicForward 7777 | ||
</pre> | </pre> | ||
==== LocalForward ==== | |||
Mittels LocalForward kann man Ports von der Host-Maschine auf die lokale Maschine forwarden. Durch folgende Zeilen kann z.B. der CUPS-Dienst ([[drucken]]) auf Port 6631 der lokalen Maschine genutzt werden (verwenden wir aber nicht mehr?): | |||
<pre> | |||
Host fbi | |||
User 9nachnam | |||
HostName rzssh1.informatik.uni-hamburg.de | |||
LocalForward 6631 linuxprint.informatik.uni-hamburg.de:631 | |||
</pre> | |||
==== ProxyJump ==== | |||
Häufig kann man sich von einem Host aus noch auf weitere Rechner einloggen, die von außen nicht zugänglich sind. Bei manchen [[#Infrastruktur_der_Institute_.2F_Fachbereiche|Instituten]] ist der von außen erreichbare Host sogar explizit als Login-Node gedacht, also nur dafür, dass man sich von hier weiterverbindet. Beim [[#ZBH|ZBH]] ist man sogar darauf angewiesen, sich auf einen anderen Rechner weiterzuverbinden, weil man für gewöhnlich auf dem Login-Node kein home-Verzeichnis hat. In solchen Situationen kann man ProxyJump verwenden, wie hier im Fall für ccblade1: | |||
<pre> | |||
Host ccblade1 | |||
User 0bock | |||
HostName ccblade1 | |||
ProxyJump fbi | |||
</pre> | |||
Falls man den Namen des Hosts erst auf dem Proxy-Rechner ermitteln möchte oder z.B. erst herausfinden möchte, welcher Rechner denn verfügbar ist, kann man ProxyCommand verwenden. | |||
==== | ==== ProxyCommand ==== | ||
Mit | |||
Mit ProxyCommand kann man einen Befehl angeben, der automatisch auf dem Host ausgeführt werden soll. Z.B.: | |||
<pre> | <pre> | ||
Host rzdspc* | Host rzdspc* | ||
User 4winter | User 4winter | ||
ProxyCommand ssh | ProxyCommand ssh 0bock@rzssh1.informatik.uni-hamburg.de /opt/bin/netcat %h %p 2> /dev/null | ||
</pre> | </pre> | ||
Zeile 52: | Zeile 119: | ||
Last cluster login: Sun Oct 7 14:03:05 on rzdspc6 | Last cluster login: Sun Oct 7 14:03:05 on rzdspc6 | ||
rzdspc6$ | rzdspc6$ | ||
</pre> | |||
==== Port ==== | |||
Standardmäßig läuft SSH auf dem Port 22. Falls man einen anderen Port braucht, wie z.B. beim [[#ZBH|ZBH]], geht das mit | |||
<pre> | |||
Host foo | |||
User bar | |||
HostName qux | |||
Port 42 | |||
</pre> | |||
oder per Parameter | |||
<pre> | |||
$ ssh -p 42 <host> | |||
</pre> | |||
Vorsicht: Bei [[#Dateitransfer|scp]] wird der Parameter groß geschrieben: | |||
<pre> | |||
$ scp -P 42 <host>:~/eine/datei ./ | |||
</pre> | |||
==== Kompression ==== | |||
SSH kann die Datenströme zwischen dem Host und deinem Rechner auch komprimieren. Da heutige Rechner in der Regel schneller komprimieren können, als die Netzwerkverbindung zum Host schnell ist, ist das in den allermeisten Fällen ein Performance-Gewinn und kann deshalb auch relativ bedenkenlos für alle Hosts angeschaltet werden: | |||
<pre> | |||
Host * | |||
Compression yes | |||
</pre> | |||
Alternativ geht das über den Parameter | |||
<pre> | |||
$ ssh -C <host> | |||
</pre> | |||
==== Das "Broken-Pipe"-Problem ==== | |||
Wer häufiger Probleme mit der Meldung "Broken Pipe" hat, wenn man eine Weile keine Befehle per SSH eingegeben hat, wenn der Rechner kurz die Netzwerkverbindung verliert, Pakete verloren gehen, oder man seinen Rechner kurz in den Standby versetzt hat, sind vllt. folgende Zeilen eine Lösung, die eigentlich auch für alle Hosts angewendet werden können: | |||
<pre> | |||
Host * | |||
ServerAliveInterval 30 | |||
ServerAliveCountMax 100 | |||
TCPKeepAlive yes | |||
</pre> | </pre> | ||
=== | === Anmelden ohne Passwort-Eingabe === | ||
Vom Laptop im Netz des Informatikum anmelden, ohne jedesmal das Passwort eingeben zu müssen? | Vom Laptop im Netz des Informatikum anmelden, ohne jedesmal das Passwort eingeben zu müssen? | ||
Das geht auf mehrere Arten, wobei nur eine wirklich als sicher bezeichnet werden kann, nämlich [[#Public-Key-Authentifizierung|Public-Key-Authentifizierung]]. | |||
*Mit anderen Worten: Wenn Public-Key-Authentifizierung funktioniert, dann immer Public-Key-Authentifizierung verwenden!* | |||
==== Public-Key-Authentifizierung ==== | |||
Auf dem eigenen Laptop muss zuerst ein Public/Private-Schlüsselpaar erstellt werden. Das funktioniert durch das Programm "ssh-keygen" und sieht dann etwa so aus: | Auf dem eigenen Laptop muss zuerst ein Public/Private-Schlüsselpaar erstellt werden. Das funktioniert durch das Programm "ssh-keygen" und sieht dann etwa so aus: | ||
<pre> | <pre> | ||
olli@desktop:~$ ssh-keygen | olli@desktop:~$ ssh-keygen | ||
Generating public/private rsa key pair. | Generating public/private rsa key pair. | ||
Enter file in which to save the key (/home/olli/.ssh/id_rsa): | Enter file in which to save the key (/home/olli/.ssh/id_rsa): | ||
Enter passphrase (empty for no passphrase): | Enter passphrase (empty for no passphrase): | ||
Enter same passphrase again: | Enter same passphrase again: | ||
Your identification has been saved in /home/olli/.ssh/id_rsa. | Your identification has been saved in /home/olli/.ssh/id_rsa. | ||
Your public key has been saved in /home/olli/.ssh/id_rsa.pub. | Your public key has been saved in /home/olli/.ssh/id_rsa.pub. | ||
Zeile 80: | Zeile 188: | ||
Falls man das Programm ssh-copy-id nicht hat, kann man den Vorgang auch per Hand durchführen. Man kopiert die Datei "~/.ssh/id_rsa.pub" vom Client, also da wo man sie erstellt hat, auf den Zielrechner, loggt sich dann an dem Zielrechner ein und kopiert den Inhalt ans Ende der Datei ~/.ssh/authorized_keys. "cat mein-key.pub >> ~/.ssh/authorized_keys" auf dem Server ausgeführt reicht dann. | Falls man das Programm ssh-copy-id nicht hat, kann man den Vorgang auch per Hand durchführen. Man kopiert die Datei "~/.ssh/id_rsa.pub" vom Client, also da wo man sie erstellt hat, auf den Zielrechner, loggt sich dann an dem Zielrechner ein und kopiert den Inhalt ans Ende der Datei ~/.ssh/authorized_keys. "cat mein-key.pub >> ~/.ssh/authorized_keys" auf dem Server ausgeführt reicht dann. | ||
=== expect === | ==== expect ==== | ||
Expect ist ein kleines Programm, was einen Prozess startet und auf Ausgaben dieses Prozess wartet, um dann Eingaben an den Prozess zu senden. Nun kann man expect nutzen um ein einfaches "login"-Script für die UHH-Firewall zu schreiben, da dort Public-Key Authentifizierung nicht möglich ist. | Expect ist ein kleines Programm, was einen Prozess startet und auf Ausgaben dieses Prozess wartet, um dann Eingaben an den Prozess zu senden. Nun kann man expect nutzen um ein einfaches "login"-Script für die UHH-Firewall zu schreiben, da dort Public-Key Authentifizierung nicht möglich ist. | ||
Nachteil ist natürlich, dass das eigene '''Passwort im Klartext''' im Script zu finden ist. Wenn einen das nicht stört, dann kann man sich ''expect'' installieren und folgendes in eine Datei schreiben: | Nachteil ist natürlich, dass das eigene '''Passwort im Klartext''' im Script zu finden ist. Das kann man allerdings umgehen, indem man das Passwort aus einem [[#Passwort_aus_Keyring_auslesen|Keyring]] ausliest. Wenn einen das aber nicht stört, dann kann man sich ''expect'' installieren und folgendes in eine Datei schreiben: | ||
<pre> | <pre> | ||
#!/usr/bin/expect -f | #!/usr/bin/expect -f | ||
set host " | set host "fbi" | ||
set user " | set user "0bock" | ||
set pass "geheimes-pw" | set pass "geheimes-pw" | ||
Zeile 110: | Zeile 218: | ||
chmod +x meine-datei | chmod +x meine-datei | ||
./meine-datei | ./meine-datei | ||
Ein weiterer Nachteil von der Lösung mit expect ist, dass man ohne weiteres keine Datenströme durch SSH pipen kann, um z.B. per SSH zu [[drucken]], und dass das ganze mit [[#Dateitransfer|scp]] nicht funktioiniert. | |||
Ein weiterer Vorteil allerdings ist, dass man sich hiermit auch ohne Passwort über einen Proxy / LoginNode (siehe [[#ProxyJump|ProxyJump]]) auf einen anderen Rechner einloggen kann, ohne (im schlimmsten Fall zweimal) sein Passwort eingeben zu müssen. Hierbei werden natürlich die Nachteile aus dem letzten Absatz nicht aufgehoben. | |||
Im einfachsten Fall sieht das etwa so aus (für ccblade1 über rzssh1): | |||
<pre> | |||
#!/usr/bin/expect -f | |||
set host "fbi" | |||
set user "0bock" | |||
set pass "geheimes-pw" | |||
spawn ssh -l "$user" "$host" | |||
expect "assword:" | |||
send "$pass\n" | |||
expect ">" | |||
send "ssh ccblade1\n" | |||
expect "assword:" | |||
send "$pass\n" | |||
interact | |||
</pre> | |||
==== sshpass ==== | |||
SSHPASS ist ein Programm, das ähnlich wie expect die Passworteingabe bei SSH übernehmen kann. | |||
Ein großer Vorteil ist, dass man SSHPASS sowohl mit SSH als auch SCP verwenden kann, dass man mit SSHPASS Datenströme durch SSH pipen kann, also dass z.B. [[drucken]] über SSH funktioniert, und dass man flexibler bei der Angabe zusätzlicher Paramater und spontanter Authentifizierungsprobleme etc. ist. | |||
SSHPASS kann das Passwort aus einer Datei lesen, per STDIN, als Argument, oder über die Umgebungsvariable "SSHPASS". | |||
Ein simples Beispiel sähe in etwa so aus für ssh und scp: | |||
<pre> | |||
$ echo 'geheimes-pw' | sshpass ssh <host> | |||
$ echo 'geheimes-pw' | sshpass scp <host>:~/eine/datei ./ | |||
</pre> | |||
Ein Nachteil von SSHPASS ist, dass dadurch meistens kein Einloggen auf einem Rechner hinter einem Login Node ist möglich ist, da auf dem Host nur selten ebenfalls SSHPASS installiert ist und man selbst dann auch sein Passwort irgendwie an den Host übertragen müsste. | |||
Außerdem muss man natürlich sein Passwort irgendwie im Klartext hinterlegen, wenn man sein Passwort nicht im [[#Passwort_aus_Keyring_auslesen|Schlüsselbund]] des Betriebssystems ablegen kann oder will. | |||
==== Passwort aus Keyring auslesen ==== | |||
Die beiden letzten Verfahren hatte beide den Nachteil, dass man irgendwo sein Passwort im Klartext hinterlegen muss, was unschön ist. Allerdings kann man das einfach umgehen, indem man das Passwort einfach im Schlüsselbund des eigenen Linux-Systems ablegt. Bei gtk-/gnome-basierten Distributionen kann man z.B. gnome-keyring-query benutzen. | |||
Hierfür muss man dann einmalig sein Passwort im Schlüsselbund hinterlegen: | |||
<pre> | |||
$ echo 'geheimes-pw' | gnome-keyring-query set informatik | |||
</pre> | |||
Und im folgenden kann man das Passwort nach Belieben auslesen: | |||
<pre> | |||
$ gnome-keyring-query get informatik | |||
</pre> | |||
Um es mit expect zu verwenden, kann man z.B. die Zeile, in der die Variable $pass gesetzt wird, austauschen durch: | |||
<pre> | |||
set pass [exec bash -c "echo -n \"\$(gnome-keyring-query get informatik)\""] | |||
</pre> | |||
Und mit SSHPASS kann man das folgendermaßen verwenden: | |||
<pre> | |||
$ SSHPASS="$(gnome-keyring-query get informatik)" sshpass -e ssh fbi | |||
</pre> | |||
Vielleicht hilft einem ja der folgende alias in der ~/.bashrc: | |||
<pre> | |||
sshp () { | |||
SSHPASS="$(gnome-keyring-query get "$1")" sshpass -e ssh "$1" | |||
} | |||
</pre> | |||
=== Dateitransfer === | === Dateitransfer === | ||
Zeile 139: | Zeile 315: | ||
=== Probleme === | === Probleme === | ||
* scp will nicht weil Leerzeichem im Pfad/ im Dateinamen sind: | * scp will nicht weil Leerzeichem im Pfad/ im Dateinamen sind: | ||
den Pfad in Hochkomma <code>'</code> setzen oder vor die Leerzeichen ein Backslash<code>\</code>. | den Pfad in Hochkomma <code>'</code> setzen oder vor die Leerzeichen ein Backslash<code>\</code>. | ||
'''Zwei äquivaltente Beispiele:''' | '''Zwei äquivaltente Beispiele:''' |
Version vom 15. November 2019, 12:12 Uhr
Secure SHell
Mittels SSH kann man sich von einem beliebigen Rechner auf einen anderen Rechner anmelden, z.B. auf das Informatik-Rechenzentrum mit dem Informatik-Account. Das ist nützlich, wenn man z.B. von zu Hause auf Programme und Dateien zugreifen möchte, die auf den Informatik-Rechnern liegen, oder wenn man nicht von einem Poolrechner, sondern von einem beliebigen Rechner drucken möchte. Wie SSH beim iRZ und vielen anderen Instituten funktioniert, und was man damit alles tolles machen kann, ist in diesem Artikel beschrieben.
hosts
Siehe Infrastruktur der Institute / Fachbereiche
Simples Einloggen
Mit folgendem Befehl kann man sich auf seinem iRZ-Account einfach einloggen:
$ ssh <kennung>@rzssh1.informatik.uni-hamburg.de
Um sich die nervige Tipparbeit und das Eingeben des Passworts sparen zu können, werden im Weiteren ein paar Tricks erläutert.
Konfiguration
Die ~/.ssh/config enthaelt die Konfiguration fuer deinen SSH Client. Dort kann man viele tolle Sachen machen, zB muss man nicht immer ssh rzssh1.informatik.uni-hamburg.de
machen, sondern bspw. ssh fbi
. Das ist gut.
Mit folgendem Text in deiner ~/.ssh/config kannst du das auch:
Host fbi User 9nachnam HostName rzssh1.informatik.uni-hamburg.de
Parameter / Konfigurationseinträge
Man kann bei SSH viele nützliche Parameter übergeben, allerdings die meisten (oder alle?) auch einfach in der ~/.ssh/config eintragen.
Wenn du in dieser Liste nicht fündig wirst und noch mehr tolle Sachen mit deiner SSH-Config-Datei machen willst, schau dir
man ssh_config
an.
Arbeiten mit Wildcards
In der SSH-Config können z.B. in den Hostnames Wildcards vorkommen. Dadurch ist z.B. so ein Setup möglich:
Host fbi* User 0bock [Viele weitere Einträge] Host fbi1 HostName rzssh1.informatik.uni-hamburg.de Host fbi2 Hostname rzssh2.informatik.uni-hamburg.de Host fbi HostName rzssh1.informatik.uni-hamburg.de
Wenn man viele Konfigurationseinträge hat, kann man die durch eine Wildcard sowohl auf rzssh1 als auch rzssh2 (falls rzssh1 mal down ist) anwenden, und gleichzeitig immer noch den komfortablen alias fbi dazu haben. Bei manchen Parametern kann es auch sinnvoll sein, sie mittels
Host * [Viele Einträge]
auf alle Hosts anzuwenden.
X-Forwarding
Wenn du grafische Anwendungen per SSH auf einem entfernten Host ausführen willst, so dass sie auf deinem lokalen Bildschirm angezeigt werden, kannst du SSH-Forwarding verwenden. Das geht mittels ForwardX11 in der ~/.ssh/config
Host fbi User 0bock HostName rzssh1.informatik.uni-hamburg.de ForwardX11 yes
oder per Parameter
$ ssh -X <host>
Es gibt auch ForwardX11Trusted bzw. den Parameter -Y.
Falls die Performance von X-Forwarding schlecht ist, kann man versuchen, Kompression anzuschalten.
Wenn die Performance immer noch zu schlecht ist, kann man statt direktem SSH mit X-Forwarding auch die Software X2GO ausprobieren, welche meistens eine bessere Performance hat, wofür allerdings aus dem Host der X2GO-Server installiert sein muss, wie das z.B. beim DKRZ der Fall ist.
DynamicForward
Um einen lokalen SOCKS-Proxy zum Tunneln einzurichten, kannst du DynamicForward verwenden:
Host fbi User 0bock HostName rzssh1.informatik.uni-hamburg.de DynamicForward 7777
LocalForward
Mittels LocalForward kann man Ports von der Host-Maschine auf die lokale Maschine forwarden. Durch folgende Zeilen kann z.B. der CUPS-Dienst (drucken) auf Port 6631 der lokalen Maschine genutzt werden (verwenden wir aber nicht mehr?):
Host fbi User 9nachnam HostName rzssh1.informatik.uni-hamburg.de LocalForward 6631 linuxprint.informatik.uni-hamburg.de:631
ProxyJump
Häufig kann man sich von einem Host aus noch auf weitere Rechner einloggen, die von außen nicht zugänglich sind. Bei manchen Instituten ist der von außen erreichbare Host sogar explizit als Login-Node gedacht, also nur dafür, dass man sich von hier weiterverbindet. Beim ZBH ist man sogar darauf angewiesen, sich auf einen anderen Rechner weiterzuverbinden, weil man für gewöhnlich auf dem Login-Node kein home-Verzeichnis hat. In solchen Situationen kann man ProxyJump verwenden, wie hier im Fall für ccblade1:
Host ccblade1 User 0bock HostName ccblade1 ProxyJump fbi
Falls man den Namen des Hosts erst auf dem Proxy-Rechner ermitteln möchte oder z.B. erst herausfinden möchte, welcher Rechner denn verfügbar ist, kann man ProxyCommand verwenden.
ProxyCommand
Mit ProxyCommand kann man einen Befehl angeben, der automatisch auf dem Host ausgeführt werden soll. Z.B.:
Host rzdspc* User 4winter ProxyCommand ssh 0bock@rzssh1.informatik.uni-hamburg.de /opt/bin/netcat %h %p 2> /dev/null
netcat ist allerdings meistens einfach als
netcat
oder
nc
ansprechbar. In Debian ist netcat im Paket
netcat-openbsd
enthalten.
Und nu:
teythoon@europa$ ssh rzdspc6 Last login: Sun Oct 7 14:05:16 2007 from rzdspc10.inform Sun Microsystems Inc. SunOS 5.10 Generic January 2005 Willkommen auf der SUNW,Sun-Fire-V445 rzdspc6.informatik.uni-hamburg.de Last cluster login: Sun Oct 7 14:03:05 on rzdspc6 rzdspc6$
Port
Standardmäßig läuft SSH auf dem Port 22. Falls man einen anderen Port braucht, wie z.B. beim ZBH, geht das mit
Host foo User bar HostName qux Port 42
oder per Parameter
$ ssh -p 42 <host>
Vorsicht: Bei scp wird der Parameter groß geschrieben:
$ scp -P 42 <host>:~/eine/datei ./
Kompression
SSH kann die Datenströme zwischen dem Host und deinem Rechner auch komprimieren. Da heutige Rechner in der Regel schneller komprimieren können, als die Netzwerkverbindung zum Host schnell ist, ist das in den allermeisten Fällen ein Performance-Gewinn und kann deshalb auch relativ bedenkenlos für alle Hosts angeschaltet werden:
Host * Compression yes
Alternativ geht das über den Parameter
$ ssh -C <host>
Das "Broken-Pipe"-Problem
Wer häufiger Probleme mit der Meldung "Broken Pipe" hat, wenn man eine Weile keine Befehle per SSH eingegeben hat, wenn der Rechner kurz die Netzwerkverbindung verliert, Pakete verloren gehen, oder man seinen Rechner kurz in den Standby versetzt hat, sind vllt. folgende Zeilen eine Lösung, die eigentlich auch für alle Hosts angewendet werden können:
Host * ServerAliveInterval 30 ServerAliveCountMax 100 TCPKeepAlive yes
Anmelden ohne Passwort-Eingabe
Vom Laptop im Netz des Informatikum anmelden, ohne jedesmal das Passwort eingeben zu müssen? Das geht auf mehrere Arten, wobei nur eine wirklich als sicher bezeichnet werden kann, nämlich Public-Key-Authentifizierung.
- Mit anderen Worten: Wenn Public-Key-Authentifizierung funktioniert, dann immer Public-Key-Authentifizierung verwenden!*
Public-Key-Authentifizierung
Auf dem eigenen Laptop muss zuerst ein Public/Private-Schlüsselpaar erstellt werden. Das funktioniert durch das Programm "ssh-keygen" und sieht dann etwa so aus:
olli@desktop:~$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/olli/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/olli/.ssh/id_rsa. Your public key has been saved in /home/olli/.ssh/id_rsa.pub. The key fingerprint is: bla bla olli@desktop:~$
Man kann alle Abfragen einfach mit Enter bestätigen. Nun muss man dem Server, in diesem Fall rzssh1, nur noch eine Kopie des Schlüssels zukommen lassen. Das funktioniert vom Laptop aus über ssh-copy-id:
ssh-copy-id -i ~/.ssh/id_rsa.pub 7bestman@rzssh1.informatik.uni-hamburg.de Password: *passwort* bla bla bla
der Parameter -i gibt hierbei den public-Schlüssel an... Falls man das Programm ssh-copy-id nicht hat, kann man den Vorgang auch per Hand durchführen. Man kopiert die Datei "~/.ssh/id_rsa.pub" vom Client, also da wo man sie erstellt hat, auf den Zielrechner, loggt sich dann an dem Zielrechner ein und kopiert den Inhalt ans Ende der Datei ~/.ssh/authorized_keys. "cat mein-key.pub >> ~/.ssh/authorized_keys" auf dem Server ausgeführt reicht dann.
expect
Expect ist ein kleines Programm, was einen Prozess startet und auf Ausgaben dieses Prozess wartet, um dann Eingaben an den Prozess zu senden. Nun kann man expect nutzen um ein einfaches "login"-Script für die UHH-Firewall zu schreiben, da dort Public-Key Authentifizierung nicht möglich ist.
Nachteil ist natürlich, dass das eigene Passwort im Klartext im Script zu finden ist. Das kann man allerdings umgehen, indem man das Passwort aus einem Keyring ausliest. Wenn einen das aber nicht stört, dann kann man sich expect installieren und folgendes in eine Datei schreiben:
#!/usr/bin/expect -f set host "fbi" set user "0bock" set pass "geheimes-pw" spawn ssh -l "$user" "$host" expect { "Are you sure you want to continue connecting" { send "yes\n" exp_continue } "password:" { send "$pass\n" interact } } exit
nun einfach ausführbar machen und sich ganz fix ohne Passwortabfrage einloggen
chmod +x meine-datei ./meine-datei
Ein weiterer Nachteil von der Lösung mit expect ist, dass man ohne weiteres keine Datenströme durch SSH pipen kann, um z.B. per SSH zu drucken, und dass das ganze mit scp nicht funktioiniert.
Ein weiterer Vorteil allerdings ist, dass man sich hiermit auch ohne Passwort über einen Proxy / LoginNode (siehe ProxyJump) auf einen anderen Rechner einloggen kann, ohne (im schlimmsten Fall zweimal) sein Passwort eingeben zu müssen. Hierbei werden natürlich die Nachteile aus dem letzten Absatz nicht aufgehoben. Im einfachsten Fall sieht das etwa so aus (für ccblade1 über rzssh1):
#!/usr/bin/expect -f set host "fbi" set user "0bock" set pass "geheimes-pw" spawn ssh -l "$user" "$host" expect "assword:" send "$pass\n" expect ">" send "ssh ccblade1\n" expect "assword:" send "$pass\n" interact
sshpass
SSHPASS ist ein Programm, das ähnlich wie expect die Passworteingabe bei SSH übernehmen kann.
Ein großer Vorteil ist, dass man SSHPASS sowohl mit SSH als auch SCP verwenden kann, dass man mit SSHPASS Datenströme durch SSH pipen kann, also dass z.B. drucken über SSH funktioniert, und dass man flexibler bei der Angabe zusätzlicher Paramater und spontanter Authentifizierungsprobleme etc. ist.
SSHPASS kann das Passwort aus einer Datei lesen, per STDIN, als Argument, oder über die Umgebungsvariable "SSHPASS".
Ein simples Beispiel sähe in etwa so aus für ssh und scp:
$ echo 'geheimes-pw' | sshpass ssh <host> $ echo 'geheimes-pw' | sshpass scp <host>:~/eine/datei ./
Ein Nachteil von SSHPASS ist, dass dadurch meistens kein Einloggen auf einem Rechner hinter einem Login Node ist möglich ist, da auf dem Host nur selten ebenfalls SSHPASS installiert ist und man selbst dann auch sein Passwort irgendwie an den Host übertragen müsste.
Außerdem muss man natürlich sein Passwort irgendwie im Klartext hinterlegen, wenn man sein Passwort nicht im Schlüsselbund des Betriebssystems ablegen kann oder will.
Passwort aus Keyring auslesen
Die beiden letzten Verfahren hatte beide den Nachteil, dass man irgendwo sein Passwort im Klartext hinterlegen muss, was unschön ist. Allerdings kann man das einfach umgehen, indem man das Passwort einfach im Schlüsselbund des eigenen Linux-Systems ablegt. Bei gtk-/gnome-basierten Distributionen kann man z.B. gnome-keyring-query benutzen. Hierfür muss man dann einmalig sein Passwort im Schlüsselbund hinterlegen:
$ echo 'geheimes-pw' | gnome-keyring-query set informatik
Und im folgenden kann man das Passwort nach Belieben auslesen:
$ gnome-keyring-query get informatik
Um es mit expect zu verwenden, kann man z.B. die Zeile, in der die Variable $pass gesetzt wird, austauschen durch:
set pass [exec bash -c "echo -n \"\$(gnome-keyring-query get informatik)\""]
Und mit SSHPASS kann man das folgendermaßen verwenden:
$ SSHPASS="$(gnome-keyring-query get informatik)" sshpass -e ssh fbi
Vielleicht hilft einem ja der folgende alias in der ~/.bashrc:
sshp () { SSHPASS="$(gnome-keyring-query get "$1")" sshpass -e ssh "$1" }
Dateitransfer
Per Software wie FileZilla kann auch unter Windows und mit einer grafischen Oberfläche eine Verbindung mit dem eigenen Laufwerk am Informatikum hergestellt werden, um Dateien beispielsweise auf den eigenen Rechner zu Hause zu kopieren. Dafür gibt man folgendes ein: Server:sftp://rzssh1.informatik.uni-hamburg.de Benutzername: <Informatik-Kennung> Passwort: <eigenes Passwort> Port: <einfach freilassen>
Nützliche "Tricks"
Mit Hilfe des Port Forwadings kann man auch von Zuhause aus zb das Online Computer Library Center oder die ACM Digital Library durchstöbern:
ssh -L 2222:proxyuhh.uni-hamburg.de:3128 <username>@rzssh1.informatik.uni-hamburg.de -N
und dann im Browser als Proxy "localhost" mit Port 2222 eintragen. Nachdem man die Verbindung wieder getrennt hat natürlich nicht vergessen, die Proxyeinstellungen im Browser wieder zurückzusetzen.
Dieses Plugin macht es dem Firefox-User leichter, zwischen Proxies umzuschalten.
Unter Linux kann man auch so Verbindungen umleiten:
# iptables -t nat -I OUTPUT -d 134.100.9.77 -p tcp --dport 80 -j DNAT --to 127.0.0.1:1234
$ ssh -L1234:134.100.9.77:80 <username>@rzssh1.informatik.uni-hamburg.de
Ist zwar nicht sehr komfortabel, aber es funktioniert quasi immer; z. B. wenn man kein Proxy einstellen kann und Programme wie tsocks nicht funktionieren sollten.
Probleme
- scp will nicht weil Leerzeichem im Pfad/ im Dateinamen sind:
den Pfad in Hochkomma '
setzen oder vor die Leerzeichen ein Backslash\
.
Zwei äquivaltente Beispiele:
Beispiel#$ scp ~/Pfad/z\ u\ r/Datei/Filename\ mit\ Leerzeichen 4user@rzssh1:~/Zielpfad\ mit\ Leerzei\ chen/fuer/die/Datei/.
Beispiel#$ scp '~/Pfad/z u r/Datei/Filename mit Leerzeichen' 4user@rzssh1:'~/Zielpfad mit Leerzei chen/fuer/die/Datei/.'
- das Kopieren vieler kleiner Dateien dauert ziemlich lange?
On-the-fly archivieren und entpacken hilft:
ssh <mein-host> 'tar -c /mein/ordner/mit/kleinen/dateien | gzip' | gzip -d | tar -xv
Mit dem Schalter -z Spart man sich die beiden gzip Kommandos.
ssh <mein-host> "tar -cz /mein/ordner/mit/kleinen/dateien" | tar -xzv
Ausserdem kann man bei tar noch das Zielverzeichnis angeben und eventuell eine schnellere Verschlüsselung für ssh benutzen. Bei langsamen Rechnern und hoher Bandbreite macht es Sinn, auf die Kompression zu verzichten.
ssh -c blowfish <mein-host> "tar -c /mein/ordner/mit/kleinen/dateien" | tar -xv -C /hier/hin/
Infrastruktur der Institute / Fachbereiche
Informatikum / iRZ
Am Informatikum gibt es die Knoten rzssh{1,2}.informatik.uni-hamburg.de, auf die man sich mit seiner Informatik-Kennung anmelden kann.
Für rechenaufwändige Anwendungen gibt es die ccblades ccblade{1,9}, auf die man sich per SSH von rzssh{1,2} anmelden kann, welche eine Woche im voraus über das iRZ reserviert werden können.
DKRZ
Am Deutschen Klimarechenzentrum gibt es den Login-Cluster cluster.wr.informatik.uni-hamburg.de, auf die man sich mit der Kennung anmelden kann, die man in seinem ersten Modul in der Arbeitsgruppe Wissenschaftliches Rechnen erhält, welche Cluster-Zugang erfordert.
Der Login-Cluster sollte nicht für rechenaufwändige Jobs / Benchmarks genutzt werden, dafür gibt es die Compute Nodes abu{1..5}, amd{2..4}, magny1, nehalem5, und west{1..10} mit jeweils unterschiedlicher Ausstattung. Bevor man sich allerdings auf einen Node einloggen kann, muss man ihn sich erst mit dem Batch-Queuing-System SLURM allozieren. Das geht für einen beliebigen Knoten der Partition "west" z.B. so:
$ salloc -p west salloc: Granted job allocation 26477 $ squeue JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 26477 west bash felgenha R 0:03 1 west2 $ ssh west2
Oder wenn man z.B. explizit west7 haben möchte:
$ salloc -p west -w west7 salloc: Granted job allocation 26479 $ ssh west7
ZBH
Das Zentrum für Bioinformatik hat auch einen Login-Node, welcher unter der Adresse bari.zbh.uni-hamburg.de zu erreichen ist, allerdings nur über Port 7373 (-p 7373 bei SSH, -P 7373 bei SCP, oder Zeile "Port" in der SSH-Config).
Von hier aus kann man sich unter anderem auf die Desktop-Rechner per SSH verbinden, welche die Namen von Seen (mondsee, chiemsee, ...), Inseln (ruegen, ...), oder ähnlichem tragen. Die Desktop-Rechner werden gleichzeitig als Teil eines Compute Clusters eingesetzt. Allerdings funktionieren die Kennungen von Studierenden, die lediglich Programmierung für Naturwissenschaften machen, meistens nur auf den Seen.
Da die meisten Studierenden auf bari kein home-Verzeichnis haben, erübrigt sich Public-Key-Authentifizierung. Man kann natürlich mit einem ProxyJump arbeiten, muss dann aber zweimal sein Passwort eingeben, oder man verwendet sshpass, muss dann aber im ZBH noch einmal sein Passwort eingeben, oder man verwendet ein expect-Skript, wodurch man zwar sein Passwort nicht mehr eingeben muss, aber auch keine mehr Dateien durch SSH pipen kann.
RRZ
Das Regionale Rechenzentrum (RRZ) hat auch zwei SSH-Server (rrzlogin{,2}.rrz.uni-hamburg.de), die sind aber schlecht.
Es gibt wohl auch Compute Nodes, z.B. Hummel.
Physik / Physnet
In der Physik gibt es die Login-Nodes login{1..4}.physnet.uni-hamburg.de
Von dort kann man sich weiterverbinden auf die Nodes compile{1,2}, welche für Testen, Kompilieren, und kurze rechenintensive Arbeiten gedacht sind, und graphix{01,02}, welche wie compile{1,2} sind, aber mit GPUs.
Falls man allerdings in der Physik per SSH drucken möchte, muss man sich auf einen der studentischen Arbeitsrechner einloggen (falls einer gerade läuft), welche studix{01..26} heißen.