Sitzung: Jeden Freitag in der Vorlesungszeit ab 16 Uhr c. t. im MAR 0.005. In der vorlesungsfreien Zeit unregelmäßig (Jemensch da?). Macht mit!

SSH: Unterschied zwischen den Versionen

K (→‎SSH-Optionen speichern)
(Update Server)
 
(53 dazwischenliegende Versionen von 14 Benutzern werden nicht angezeigt)
Zeile 11: Zeile 11:
 
Wo nicht anders angegeben, bezieht sich die weitere Beschreibung auf die OpenSSH-Implementierung. Diese gehört in modernen Linuxdistributionen und im Fakultätsnetz zur Standardausrüstung.
 
Wo nicht anders angegeben, bezieht sich die weitere Beschreibung auf die OpenSSH-Implementierung. Diese gehört in modernen Linuxdistributionen und im Fakultätsnetz zur Standardausrüstung.
  
−
== SSH für den Zugriff auf das Fakultätsnetz ==
+
== SSH für den Zugriff auf das [https://www.eecs.tu-berlin.de/eecsit/v/dienste/externer_zugriff/ Fakultätsnetz] ==
  
 
Per SSH könnt ihr auch bequem von zu Hause aus auf das Fakultätsnetz zugreifen und auf den Workstations oder Servern in der Uni Kommandos ausführen oder Dateien aus oder in den eigenen Bereich kopieren.
 
Per SSH könnt ihr auch bequem von zu Hause aus auf das Fakultätsnetz zugreifen und auf den Workstations oder Servern in der Uni Kommandos ausführen oder Dateien aus oder in den eigenen Bereich kopieren.
  
−
=== Liste der Server im CS-Netz ===
+
'''Achtung!''' Seit März 2020 kann nur noch innerhalb des Uninetzes auf die Server zugegriffen werden. Daher ist es nötig sich entweder vorher über [[SSH#sshgate|sshgate]] zu verbinden oder über [[VPN|VPN]] verbunden zu sein.
  
−
Achtung, die Liste hier ist nicht mehr aktuell. Insbesondere stimmt die Kern/Thread Anzahl oft nicht mehr.
+
=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===
  
−
Auf folgenden Rechnern des IRB können sich Studenten einloggen:
+
Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 28.04.2022). Falls ihr Abweichungen entdeckt, aktualisiert sie doch bitte.
 +
 
 +
Auf folgenden Rechnern des eecsIT können sich Studierende mit ihrem tubIT-Account einloggen:
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|- class="hintergrundfarbe5"
 
|- class="hintergrundfarbe5"
−
! Rechnername             !! tubit-Account  !! CS-Account !! Kerne !! Threads !! GhZ / Kern !! OS
+
! Rechnername                       !! Kerne                      !! GhZ / Kern !! RAM !! OS !! Release  !! Kommentar
−
|-
 
−
|fiesta.cs.tu-berlin.de    || nein || ja || 16*UltraSparc T2 || 128 || 1,4 || SunOS
 
−
|-
 
−
|bolero.cs.tu-berlin.de    || nein || ja || 8*UltraSPARC-III+ || 8 || 0,9 || SunOS
 
−
|-
 
−
|bird.cs.tu-berlin.de      || nein || ja || || || || SunOS
 
−
|-
 
−
|caramba.cs.tu-berlin.de  || nein || ja || || || || SunOS
 
−
|-
 
−
|cartero.cs.tu-berlin.de  || nein || ja || || || || SunOS
 
−
|-
 
−
|bruja.cs.tu-berlin.de    || nein || ja || || || || SunOS
 
−
|-
 
−
|brujo.cs.tu-berlin.de    || nein || ja || || || || SunOS
 
−
|-
 
−
|pepita.cs.tu-berlin.de    || nein || ja || || || || SunOS
 
−
|-
 
−
|pepino.cs.tu-berlin.de    || nein || ja || || || || SunOS
 
−
|-
 
−
|condesa.cs.tu-berlin.de  || nein || ja || || || || SunOS
 
 
|-
 
|-
−
|bonito.cs.tu-berlin.de    || nein || ja || || || || SunOS
+
|borrasca-ubu.eecsit.tu-berlin.de    || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 20.04.4 LTS || ubu20
 
|-
 
|-
−
|caro.cs.tu-berlin.de     || nein || ja || || || || SunOS
+
|casa-ubu.eecsit.tu-berlin.de       || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 20.04.4 LTS || ubu20
 
|-
 
|-
−
|conde.cs.tu-berlin.de     || nein || ja || || || || SunOS
+
|cascada-ubu.eecsit.tu-berlin.de     || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 20.04.4 LTS || ubu20
 
|-
 
|-
−
|hombre.cs.tu-berlin.de    || ja || nein || UltraSPARC-T2+ || 128 || 1,415 || SunOS
+
|emmerich-ubu.eecsit.tu-berlin.de    || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
 
|-
 
|-
−
|pronto.cs.tu-berlin.de   || ja || nein || UltraSPARC-T2+ || 128 || 1,415 || SunOS
+
|furor-ubu.eecsit.tu-berlin.de       || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
 
|-
 
|-
−
|bazar.cs.tu-berlin.de     || ja || nein || UltraSPARC-T2 || 64 || 1,165 || SunOS
+
|gata-ubu.eecsit.tu-berlin.de       || ???                        || ?,?? || ??G || ???  || ???        || Offline
 
|-
 
|-
−
|siesta.cs.tu-berlin.de   || ja || nein || UltraSPARC-T2 || 64 || 1,165 || SunOS
+
|gato-ubu.eecsit.tu-berlin.de       || ???                        || ?,?? || ??G || ???   || ???        || Offline
−
|-
 
−
|quepasa.cs.tu-berlin.de   || ja || nein || UltraSPARC-T2 || 64 || 1,165 ||
 
 
|-
 
|-
−
|sombrero.cs.tu-berlin.de || ja || nein || UltraSPARC-T2 || 64 || 1,165 || SunOS
+
|kelbassa-ubu.eecsit.tu-berlin.de   || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 18.04.6 LTS ||  
 
|-
 
|-
−
|tienda.cs.tu-berlin.de || ja || nein || UltraSPARC-T2 || 64 || 1,165 || SunOS
+
|kelbassa-ware.eecsit.tu-berlin.de   || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 20.04.4 LTS ||  
 
|-
 
|-
−
|manana.cs.tu-berlin.de || ja || nein || UltraSPARC-T2 || 64 || 1,165 || SunOS
+
|kurrat-ubu.eecsit.tu-berlin.de     || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
 
|-
 
|-
−
|trueno.cs.tu-berlin.de || ja || nein || UltraSPARC-T2 || 64 || 1,165 || SunOS
+
|tilkowski-ubu.eecsit.tu-berlin.de   || 16 * Intel Xeon E5-2690 v4  || 2,60 || 16G || Ubuntu || 20.04.4 LTS ||
 
|-
 
|-
−
|kiosco.cs.tu-berlin.de || ja || nein || UltraSPARC-T2+ || 128 || 1,415 || SunOS
+
|toro-ubu.eecsit.tu-berlin.de       || 32 * Intel Xeon E5-2690 v4  || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
 
|-
 
|-
−
|furor.cs.tu-berlin.de    || ja || nein || 8 * Intel Xeon E5440 || || 2,003 || Ubuntu
+
|turbador-ubu.eecsit.tu-berlin.de    || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.4 LTS || ubu20
 
|-
 
|-
−
|cascada.cs.tu-berlin.de  || ja || nein || 8 * Intel Xeon E5440  ||  || 2,826 || Ubuntu
 
−
|-
 
−
|turbador.cs.tu-berlin.de || ja || nein || 8 * Intel Xeon E5440  ||  || 2,826 || Ubuntu
 
−
|-
 
−
|racha.cs.tu-berlin.de || ja || nein || 16 * Intel Xeon E5440  ||  || 2,826 || Ubuntu
 
−
|-
 
−
|torero.cs.tu-berlin.de || ja || nein || 16 * Intel Xeon E5440  ||  || 2,826 || Ubuntu
 
 
|}
 
|}
  
−
Desweiteren wird mit sshgate.tu-berlin.de [http://www.tubit.tu-berlin.de/menue/dienste/internet/ssh_zugang/ von tubIT] Zugriff auf zwei Solarisrechner angeboten. Auf diesen Systemen ist außer Vim kaum weitere Software installiert. Jedoch kann es z. B. benutzt werden, um via sshfs einfach Zugriff auf die AFS-Daten zu erhalten, ACLs zu pflegen oder auf TU-interne Dienste zuzugreifen. (z.B. ssh auf tu-rechner, etc)
+
Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18, Ubuntu20), falls mehrere verschiedene vorhanden sind.
 +
 
 +
==== sshgate ====
 +
Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von ZE Campusmanagement] Zugriff auf einen RHEL-Server angeboten. Auf diesem System ist außer einfachen Editoren und grundlegender Software kaum weiteres installiert. Jedoch kann es z. B. benutzt werden, um via sshfs einfach Zugriff auf die AFS-Daten zu erhalten, ACLs zu pflegen oder auf TU-interne Dienste zuzugreifen (z.B. SSH auf TU-Server / -Rechner, etc).
  
 
=== Arbeiten auf den Rechnern in der Uni ===
 
=== Arbeiten auf den Rechnern in der Uni ===
Zeile 90: Zeile 66:
 
  ssh ''rechnername''
 
  ssh ''rechnername''
  
−
Das Ergebnis ist im Allgemeneinen eine Shell auf dem angegebenen Rechner mit den Rechten des angegebenen Benutzers.
+
Das Ergebnis ist im Allgemeinen eine Shell auf dem angegebenen Rechner mit den Rechten des angegebenen Benutzers.
  
 
Als Rechnernamen könnt Ihr alle in der Tabelle oben angegebenen Rechner im Fakultätsnetz verwenden, Ihr müsst nur darauf achten, welche Art von Account ihr besitzt. Alle seit 2009 erstellten Accounts sind in der Regel reine tubit-Accounts.
 
Als Rechnernamen könnt Ihr alle in der Tabelle oben angegebenen Rechner im Fakultätsnetz verwenden, Ihr müsst nur darauf achten, welche Art von Account ihr besitzt. Alle seit 2009 erstellten Accounts sind in der Regel reine tubit-Accounts.
Zeile 98: Zeile 74:
 
Wenn ihr auf einem Unix/Linux-Rechner (oder auch unter Windows, wenn Ihr einen X-Server installiert habt) arbeitet, besteht auch die Möglichkeit, grafische Programme auf Rechnern in der Uni zu starten und die Ausgabe auf den heimischen Rechner umzuleiten, dies wird als X11-Forwarding bezeichnet.
 
Wenn ihr auf einem Unix/Linux-Rechner (oder auch unter Windows, wenn Ihr einen X-Server installiert habt) arbeitet, besteht auch die Möglichkeit, grafische Programme auf Rechnern in der Uni zu starten und die Ausgabe auf den heimischen Rechner umzuleiten, dies wird als X11-Forwarding bezeichnet.
  
 +
==== Grafische Verbindung ====
 +
 +
Für eine grafische Verbindung gibt es aktuell zwei Möglichkeiten über SSH (neben RDP und VNC): Das etwas ältere X11-Forwarding oder die etwas neuere Variante über x2go.
 +
 +
===== X2go =====
 +
 +
Hierzu wird der sog. [https://wiki.x2go.org/doku.php/doc:installation:x2goclient X2go-Client] benötigt, dieser lässt sich für jede Distribution idR. über den Paketmanager installieren (es gibt auch Versionen für Windows und Mac). Der Vorteil von X2go liegt bei der etwas einfacheren Verwendung, auch außerhalb des Uninetzes und einer schnelleren Verbindung der Oberflächen.
 +
 +
X2go bietet sowohl die komplette Anzeige eines Desktops in einem Fenster, ähnlich RDP und VNC, als auch "seamless" angezeigte Fenster, also so ab diese lokal laufen würden.
 +
 +
Im X2Go client einfach folgende Sitzungseinstellungen eintragen:
 +
- Sitzungsname: <frei wählen>
 +
- Host: Bspw. ubu18.eecsit.tu-berlin.de, siehe obige Tabelle
 +
- Proxy-Server aktivieren
 +
  - Host: sshgate.tu-berlin.de
 +
  - Gleiche Anmeldung wie für X2GO-Server
 +
  - Gleiches Kennwort wie für X2GO-Server
 +
- Sitzungsart: Entweder bspw. "LXDE" für eine vollständige Sitzung mit Desktop, oder "Anwendung" und "xfce4-terminal" für ein Terminal, über das dann entsprechende Programme ("firefox", "gedit", usw.) gestartet werden können.
 +
 +
In den restlichen Tabs muss idR. nichts verändert werden, bei "Ein-/Ausgabe" lässt sich bei Benutzen einer vollständigen Sitzung jedoch die Auflösung/Größe des Desktops und der Vollbildmodus ändern.
 +
 +
===== X11-Forwarding =====
 
Um X11-Forwarding zu aktivieren, muss beim Aufruf der Parameter <code>-X</code> mit angegeben werden. Falls es zu Problemen mit Anwendungen kommt, kann die unsichere Variante <code>-Y</code> verwendet werden. Allerdings werden dadurch serverseitige Befehle, welche die Sicherheit gefährden können, nicht gefiltert. Es empfiehlt sich vor allem bei langsamen Internetzugängen (Modem, ISDN, ADSL), die Verbindung zu komprimieren (<code>-C</code>):
 
Um X11-Forwarding zu aktivieren, muss beim Aufruf der Parameter <code>-X</code> mit angegeben werden. Falls es zu Problemen mit Anwendungen kommt, kann die unsichere Variante <code>-Y</code> verwendet werden. Allerdings werden dadurch serverseitige Befehle, welche die Sicherheit gefährden können, nicht gefiltert. Es empfiehlt sich vor allem bei langsamen Internetzugängen (Modem, ISDN, ADSL), die Verbindung zu komprimieren (<code>-C</code>):
 
  ssh -X -C ''benutzer''@''rechnername''
 
  ssh -X -C ''benutzer''@''rechnername''
Zeile 104: Zeile 102:
 
Es empfiehlt sich, aus Sicherheitsgründen immer zuerst das Forwarding mittels -X zu aktivieren - da bei -Y der Zugriff von den Unirechnern auf den Heimischen X-Desktop möglich ist.
 
Es empfiehlt sich, aus Sicherheitsgründen immer zuerst das Forwarding mittels -X zu aktivieren - da bei -Y der Zugriff von den Unirechnern auf den Heimischen X-Desktop möglich ist.
  
−
Es besteht auch die Möglichkeit, eigenes Arbeitsplatz nur als X-Terminal zum Uni-Rechnern zu nutzten. Dazu muss man auf eigenen Rechner eine X-Session nur mit Terminalfenster öffnen. Bei GDM geht das, wenn man als Session "Failsafe Terminal" wählt. Dann verbindet sich man mit X-Forwarding zum Uni-Rechner und feuert <code>gnome-session</code> ab. So wird Java Desktop System erzeugt. Man soll den Terminalfenster mit gnome-session nicht schließen, bis man sich nicht ausloggen will. Es können auch andere X-Sessions gestartet werden, wenn man die entsprechende Kommandos kennt,
+
Es besteht auch die Möglichkeit, den eigenen Arbeitsplatz nur als X-Terminal zum Uni-Rechnern zu nutzen. Dazu muss man auf dem eigenen Rechner eine X-Session mit nur einem Terminalfenster öffnen. Bei GDM geht das, wenn man als Session "Failsafe Terminal" wählt. Dann verbindet sich man mit X-Forwarding zum Uni-Rechner und feuert <code>gnome-session</code> ab. So wird Java Desktop System erzeugt. Man soll das Terminalfenster mit der gnome-session nicht schließen, solange die Verbindung besteht. Es können auch andere X-Sessions gestartet werden, mit den entsprechenden Befehlen wie z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.
−
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.
+
 
 +
==== Passwortloser Login ====
 +
Wer keine Lust hat, bei jedem Login ein Passwort einzugeben, kann stattdessen die Kerberos-Authentifizierung (bei ''ubu**.eecsit.tu-berlin.de''-Servern) oder Public-Key-Authentifizierung (bei allen anderen Servern) benutzen.
 +
 
 +
===== Kerberos-Authentifizierung =====
 +
'''Hinweis:''' Für die Server mit tubit-Authentifizierung funktioniert die gewohnte Public-Key-Authentifizierung nicht so einfach, da hier das Homeverzeichnis per AFS von ZECM gemounted wird und dazu ein Kerberos-Ticket notwendig ist. Du musst Kerberos/[[AFS]] installieren, ein Ticket per
 +
kinit -f "user"@TU-BERLIN.DE
 +
erzeugen und dann ein paar SSH-Configs setzen:
 +
ssh "user"@"hostname" -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes
 +
Dann sollte der Login ohne Passwortabfrage klappen.
 +
 
 +
Um diesen Sermon nicht jedesmal neu eingeben zu müssen, kann man sich eine Konfigurationsdatei für ssh anlegen, siehe dazu auch das Beispiel im Absatz [[SSH#SSH-Optionen_speichern]]. Auch kann beispielsweise Gnome3 ein solches Ticket erzeugen.
  
−
Wer keine Lust hat, bei jedem Login ein Passwort einzugeben, kann statt dessen Public-Key-Authentifizierung benutzen. Dazu erstellt man, sofern noch nicht geschehen, zu Hause einen öffentlichen und einen privaten Schlüssel für SSH, zum Beispiel mit
+
===== Public-Key-Authentifizierung =====
 +
Dazu erstellt man, sofern noch nicht geschehen, zu Hause einen öffentlichen und einen privaten Schlüssel für SSH, zum Beispiel mit
 
  ssh-keygen -t rsa
 
  ssh-keygen -t rsa
 
und leerer Passphrase, kopiert dann die soeben erstellte Datei id_rsa.pub ('''nicht''' id_rsa - die ist geheim!) mit scp ins Homeverzeichnis im Fakultätsnetz. Verbindet euch danach per SSH dorthin und führt dort
 
und leerer Passphrase, kopiert dann die soeben erstellte Datei id_rsa.pub ('''nicht''' id_rsa - die ist geheim!) mit scp ins Homeverzeichnis im Fakultätsnetz. Verbindet euch danach per SSH dorthin und führt dort
Zeile 113: Zeile 123:
 
aus. Die kopierte Datei kann danach entfernt werden. (Vorsicht: $HOME/.ssh/id_rsa* '''nicht''' löschen.)
 
aus. Die kopierte Datei kann danach entfernt werden. (Vorsicht: $HOME/.ssh/id_rsa* '''nicht''' löschen.)
  
−
==== Authentifizierung ohne Passwort auf den neuen Servern ====
+
==== Lange Prozesse z.B. über Nacht ====
−
'''Hinweis:''' Für die neuen Server mit tubit-Authentifizierung funktioniert dies leider nicht so einfach, da hier das Homeverzeichnis per AFS von tubit gemounted wird und dazu ein Kerberos-Ticket notwendig ist. Du musst Kerberos/[[AFS]] installieren, ein Ticket per <code>kinit user@TU-BERLIN.DE</code> erzeugen und dann ein paar SSH-Configs setzen: <code>ssh user@hostname -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes</code>. Dann sollte der Login ohne Passwortabfrage klappen.
+
Manchmal ist es nötig, Prozesse über längere Zeit auf den Servern auszuführen, bspw. Simulationen oder lange Berechnungen ohne den eigenen PC anzulassen, bzw. ständig eingeloggt zu sein. Dies ist allgemein nur eingeschränkt möglich, da die Server aktuell jeden Tag um 06:00 neugestartet werden.
 +
 
 +
Ein zweites, jedoch umgängliches Problem ist, dass die Server nach dem Ausloggen die Verbindung zum [[Tubit-AFS]] getrennt wird, wodurch keine Lese- und Schreibvorgänge auf diesem mehr möglich sind. Darin enthalten sind das '''Homeverzeichnis''' des Benutzers und evtl. '''bereitgestellte Programme''' der Modulorganisatoren.  
  
−
Um diesen Sermon nicht jedesmal neu eingeben zu müssen, kann man sich eine Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.
+
Nachfolgend ein Weg, zumindest Prozesse bis zum nächsten Neustart des Servers auszuführen:
 +
* Per SSH sich einloggen ([[SSH#Arbeiten_auf_den_Rechnern_in_der_Uni]])
 +
* Folgende Befehle nacheinander ausführen (''sessionname'' kann ein beliebig gewählter Name sein):
 +
$ pagsh
 +
$ KRB5CCNAME=FILE:`mktemp -p /tmp krb5cc_screen_XXXXXX`
 +
$ kinit -l 1d
 +
$ aklog
 +
$ screen -S sessionname
 +
* Nach dem screen-Befehl öffnet sich in dem Fenster eine "leere" Shell. In dieser kann nun der lange Prozess gestartet werden. Empfehlenswert ist es, diesen mit ''&'' am Ende zu starten (sowie den Output in eine Logdatei, also ''command > log.txt 2>&1 &''), sodass dieser im Hintergrund gestartet wird. Es wird eine sog. '''PID''' ausgegeben, diese sollte sich gemerkt / aufgeschrieben werden, falls ein vorzeitiges Beenden des Prozesses (mit ''kill'') nötig sein sollte. Anschließend lässt sich folgender Befehl ausführen, der eine Erneuerung des Kerberos-Tickets (was nur 10h gültig ist) alle 5h bewirkt:
 +
$ while true; do sleep 18000; krenew; aklog; done;
 +
* Nachdem nun alle Prozesse laufen, [''STRG+A''], dann [''d''] drücken, um die screen-session in den Hintergrund zu schieben
 +
* Zweimal nacheinander "exit" eingeben (einmal um pagsh zu verlassen, das zweite Mal um die ssh-Verbindung zu schließen). Nun ist die SSH-Verbindung geschlossen, der Prozess wird jedoch weiterlaufen und Zugriff auf das AFS bleibt bestehen.
 +
* Um nun sich erneut mit der screen-session zu verbinden folgenden Befehl ausführen (nachdem sich mit dem Server verbunden wurde):
 +
$ screen -d -r sessionname
 +
* Nach getaner Arbeit lassen sich nun noch die Spuren (Kerberostickets) verwischen / löschen mit (in der screen-session ausführen)
 +
$ kdestroy
 +
$ unlog
 +
$ exit
 +
$ exit
 +
$ exit
  
 
=== SSH-Optionen speichern ===
 
=== SSH-Optionen speichern ===
  
−
in der Datei ~/.ssh/config kann man seine Defaults abspeichern. Unser Beispiel sieht folgendermaßen aus:
+
in der Datei ~/.ssh/config kann man seine Defaults abspeichern. Hier kommt es jetzt sehr darauf an, was man machen möchte.
 +
 
 +
Wenn man auf seinem Notebook Kerberos installiert hat, und mittels des kinit-Kommandos ein Kerberos Ticket geholt hat, kann man sich an den Servern per Kerberos authentifizieren, die GSSAPI-Optionen werden dazu für das AFS benötigt:
 +
 
 +
  Host sshgate.tu-berlin.de, sshgate
 +
    Hostname sshgate.tu-berlin.de
 +
    PubKeyAuthentication no
 +
    User <TUBIT-LOGIN OHNE @-Teil>
 +
    ForwardX11 no
 +
    ForwardAgent no
 +
    PasswordAuthentication yes
 +
    GSSAPIAuthentication yes
 +
    GSSAPIDelegateCredentials yes
 +
    GSSAPITrustDns yes
  
−
Host sshgate.tu-berlin.de, sshgate
 
−
Hostname sshgate.tu-berlin.de
 
−
User <TUBIT-LOGIN OHNE @-Teil>
 
−
ForwardAgent no
 
−
ForwardX11 no
 
−
PasswordAuthentication no
 
−
PubKeyAuthentication no
 
−
GSSAPIAuthentication yes
 
−
GSSAPIDelegateCredentials yes
 
 
   
 
   
−
Host hombre.cs.tu-berlin.de  pronto.cs.tu-berlin.de  bazar.cs.tu-berlin.de  siesta.cs.tu-berlin.de  quepasa.cs.tu-berlin.de  sombrero.cs.tu-berlin.de tienda.cs.tu-berlin.de manana.cs.tu-berlin.de trueno.cs.tu-berlin.de  kiosco.cs.tu-berlin.de  
+
Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den Servern nicht möglich, daher benutzt folgende ssh-config Passwort oder Kerberos. In dem zweiten Teil der Config wird auch eine Abkürzung für die ubu18- und ubu20-Server angelegt, sodass nicht die gesamte Domain angegeben werden muss. Außerdem besteht (auskommentiert) die Möglichkeit, den Proxyjump über das sshgate automatisch zu erledigen zu lassen, was die Benutzung eines VPNs erspart.
−
PubKeyAuthentication no
+
 
−
User <TUBIT-LOGIN ohne @-Teil>
+
  Host ubu18
−
ForwardAgent no
+
    Hostname ubu18.eecsit.tu-berlin.de
−
ForwardX11 no
+
  Host ubu20
−
PasswordAuthentication yes
+
    Hostname ubu20.eecsit.tu-berlin.de
−
GSSAPIAuthentication no
+
  Host *.eecsit.tu-berlin.de *.hpc.tu-berlin.de unu18 ubu20
−
GSSAPIDelegateCredentials no
+
    PubKeyAuthentication no
−
+
    User <TUBIT-LOGIN OHNE @-Teil>
−
Host furor.cs.tu-berlin.de cascada.cs.tu-berlin.de  turbador.cs.tu-berlin.de
+
    ForwardX11 no
−
PubKeyAuthentication no
+
    ForwardAgent no
−
User <TUBIT-LOGIN OHNE @-Teil>
+
    PasswordAuthentication yes
−
ForwardAgent no
+
    GSSAPIAuthentication yes
−
ForwardX11 no
+
    GSSAPIDelegateCredentials yes
−
PasswordAuthentication no
+
    GSSAPITrustDns yes
−
GSSAPIAuthentication yes
+
    #ProxyJump sshgate.tu-berlin.de
−
GSSAPIDelegateCredentials yes
 
  
 
Da man den SSH-Servern nicht 100% vertrauen sollte, werden in mit Config keine ssh-agent-Anfragen an den lokalen Agenten weitergeleitet und auch kein X-Forwarding erlaubt. Das kann man auf der Kommandozeile im konkreten Fall alles überschreiben, aber die Defaults sollen 'sicher' sein.
 
Da man den SSH-Servern nicht 100% vertrauen sollte, werden in mit Config keine ssh-agent-Anfragen an den lokalen Agenten weitergeleitet und auch kein X-Forwarding erlaubt. Das kann man auf der Kommandozeile im konkreten Fall alles überschreiben, aber die Defaults sollen 'sicher' sein.
Zeile 155: Zeile 189:
 
Mit Hilfe von '''scp''' oder '''sftp''' könnt Ihr auch Dateien von der Uni nach Hause kopieren oder umgekehrt. Für Windows und auch Unix/Linux gibt es dafür grafische Programme, die ähnlich wie gewöhnliche FTP-Clients aussehen und funktionieren. Viele FTP-Programme beherrschen mittlerweile auch SFTP, darunter auch [http://filezilla.sourceforge.net/ FileZilla], [http://gftp.seul.org/ gFTP] etc.
 
Mit Hilfe von '''scp''' oder '''sftp''' könnt Ihr auch Dateien von der Uni nach Hause kopieren oder umgekehrt. Für Windows und auch Unix/Linux gibt es dafür grafische Programme, die ähnlich wie gewöhnliche FTP-Clients aussehen und funktionieren. Viele FTP-Programme beherrschen mittlerweile auch SFTP, darunter auch [http://filezilla.sourceforge.net/ FileZilla], [http://gftp.seul.org/ gFTP] etc.
  
−
GNOME und KDE bieten außerdem die Möglichkeit, direkt auf SSH-Accounts mittels der Dateiverwaltung (Nautilus/Konqueror) zuzugreifen. Der URL dazu lautet: <code>sftp://BENUTZERNAME@user.cs.tu-berlin.de:22/~</code>.
+
GNOME und KDE bieten außerdem die Möglichkeit, direkt auf SSH-Accounts mittels der Dateiverwaltung (Nautilus/Konqueror) zuzugreifen. Der URL dazu lautet: <code>sftp://BENUTZERNAME@ubu20.eecsit.tu-berlin.de:22/~</code> (Alternativ das sshgate, wobei ubu18 jedoch die Möglichkeit bietet unter z.B. Gnome mit Rechtsklick direkt ein funktionierendes Terminal mit allen Tools zu öffnen).
  
 
Mit Hilfe von [[WikiPedia:Filesystem_in_Userspace|FUSE]] kann man die Daten eines anderen Rechners auch per ssh/sftp mounten, das heißt ins lokale Dateisystem einhängen.
 
Mit Hilfe von [[WikiPedia:Filesystem_in_Userspace|FUSE]] kann man die Daten eines anderen Rechners auch per ssh/sftp mounten, das heißt ins lokale Dateisystem einhängen.
Zeile 170: Zeile 204:
 
SSH kann auch allgemein eine Verbindung zu einem entfernten Rechner herstellen und als Tunnel agieren, also Daten zwischen eigenem und entferntem Rechner transportieren. Dazu zwei Beispiele.
 
SSH kann auch allgemein eine Verbindung zu einem entfernten Rechner herstellen und als Tunnel agieren, also Daten zwischen eigenem und entferntem Rechner transportieren. Dazu zwei Beispiele.
  
−
==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
+
Ein Nachteil von SSH-Tunnels ist, dass sie im Vergleich zu direkten Verbindungen einen Ressourcenoverhead hinzufügen. Deshalb sollten sie genau dann benutzt werden, wenn die zusätzliche Funktionalität tatsächlich benötigt wird.
−
Der Newsserver erlaubt den Schreibzugriff nur für Rechner im Fakultätsnetz. Mit einem Tunnel kann man das simulieren:
 
−
ssh -L localhost:20119:news.cs.tu-berlin.de:119 -l ''foo'' -T fiesta.cs.tu-berlin.de
 
−
Dabei ist 20119 die Portnummer auf dem eigenen Rechner, zu der die Verbindung weitergeleitet wird, <code>fiesta.cs.tu-berlin.de</code> der Rechner, von dem aus sie hergestellt wird und ''foo'' der eigene Benutzername im Fakultätsnetz.
 
  
−
'''Seit dem 30.12.2005 gibt es den Rechner "news.cs.tu-berlin.de" nicht mehr (abgeschaltet).
+
==== SSH als SOCKS-Proxy ====
−
Die TU verweist auf den Newsserver des DFN "News.CIS.DFN.DE"'''
 
−
Nutzerordnung unter: http://news.cis.dfn.de/dnn/
 
  
−
==== Zugriff auf <code>mailhost.cs.tu-berlin.de</code> von zu Hause ====
+
Seit einiger Zeit ist der ssh-Client auch in der Lage, als socks-Proxy zu fungieren.
  
−
Dies wird in einem eigenen Artikel beschrieben: [[Email]]
+
Dazu starte man ihn mit der Option -D8080 und gebe als SOCKS-Proxy localhost und port 8080 an. Die Felder zu HTTP/FTP-Proxy in der Konfiguration des Lieblingsbrowsers bleiben dabei leer:
  
−
==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
+
  ssh -D 8080 login@ubu18.tu-berlin.de  
−
Dank der Unibibliothek kann man von Unirechnern aus Inhalte aus dem WWW abrufen, an die man sonst nicht so leicht herankommt. Für Informatiker und/oder E-Techniker ist zum Beispiel der Zugriff auf die [http://ieeexplore.ieee.org/ IEEE-Normen] interessant; weitere Information gibt es auf der [http://www.ub.tu-berlin.de/ Homepage der Bibliothek]. Um darauf von zu Hause zuzugreifen, richtet man zum Beispiel mit
 
−
  ssh -L localhost:28080:www.cs.tu-berlin.de:81 -l ''foo'' -T fiesta.cs.tu-berlin.de
 
−
einen Tunnel zwischen dem Proxyserver im Fakultätsnetz (siehe http://irb.cs.tu-berlin.de/dienste/www/proxy.html für Portnummern) und Port 28080 auf dem eigenen Rechner über fiesta.cs.tu-berlin.de ein und stellt im Lieblingsbrowser <code>localhost</code> und Port 28080 als Proxyserver ein. ''foo'' ist dabei wieder der Benutzername.
 
  
−
==== SSH als SOCKS-Proxy ====
+
==== Portforwarding mit SSH ====
  
−
Seit einiger Zeit ist der ssh-Client auch in der Lage, als socks-Proxy zu fungieren.
+
SSH ist in der Lage entweder einen entfernten Port zum lokalen Rechner zu forwarden (bspw. ein entferntes Jupyternotebook was dann lokal im Browser geöffnet werden kann) oder eine lokalen Port zu einem Server zu transportieren (bspw. angeschlossene FPGAs an den lokalen Rechner, lediglich mit dem sehr viel ressourcenfreundlicheren Xilinx Hardwaremanager, worauf mit dem entfernt laufenden Xilinx Vivado zugegriffen wird).
−
 
 
−
Dazu starte man ihn mit der Option -D8080 und gebe als SOCKS-Proxy localhost und port 8080 an. Die Felder zu HTTP/FTP-Proxy in der Konfiguration des Lieblingsbrowsers bleiben dabei leer:
 
  
−
ssh -D 8080 login@bolero.cs.tu-berlin.de
+
Für ersteren Fall (erste Portnummer für lokal (der zu öffnende), zweite für remote (der bereits existierende Port)):
 +
  ssh -L 8080:remote-server:8080 remote-server
  
 +
Für zweiteren Fall (erste Portnummer für remote (der zu öffnende), zweite für lokal (der bereits existierende Port)):
 +
  ssh -R 3121:localhost:3121 remote-server
  
−
Ein Nachteil von SSH-Tunnels ist, dass sie im Vergleich zu direkten Verbindungen einen Ressourcenoverhead hinzufügen. Deshalb sollten sie genau dann benutzt werden, wenn die zusätzliche Funktionalität tatsächlich benötigt wird.
+
Im zweiten Fall ist jedoch beachten, dass man für Ports <1024 root-Rechte benötigt.
  
 
== Weblinks ==
 
== Weblinks ==

Aktuelle Version vom 28. April 2022, 16:22 Uhr

SSH steht für Secure Shell und bezeichnet ein Netzwerkprotokoll, mit dem man sich auf entfernten Rechnern einloggen kann, um dort Programme auszuführen. Außerdem ist es möglich, über SSH auch Dateien zu kopieren (per scp oder sftp) oder andere Protokolle zu tunneln.

SSH ist ein Ersatz für das Telnet-Protokoll, mit dem man sich ebenfalls auf anderen Rechnern einloggen kann und für FTP, das auch noch heute häufig für den Datentransfer verwendet wird. Telnet und FTP arbeiten im Gegensatz zu SSH jedoch unverschlüsselt, somit ist es einfach, die übertragenen Daten und somit auch die Passwörter von anderen Benutzern mitzulesen.

Programme

Bei allen Unix/Linux-Systemen sind SSH-Clients vorhanden und werden meist auch schon standardmäßig mitinstalliert (Kommandos: ssh, scp, sftp). Für Windows-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl PuTTY verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei PuTTY vorhanden. WinSCP ist ein weiterer SCP/SFTP-Client für Windows.

Wo nicht anders angegeben, bezieht sich die weitere Beschreibung auf die OpenSSH-Implementierung. Diese gehört in modernen Linuxdistributionen und im Fakultätsnetz zur Standardausrüstung.

SSH für den Zugriff auf das Fakultätsnetz

Per SSH könnt ihr auch bequem von zu Hause aus auf das Fakultätsnetz zugreifen und auf den Workstations oder Servern in der Uni Kommandos ausführen oder Dateien aus oder in den eigenen Bereich kopieren.

Achtung! Seit März 2020 kann nur noch innerhalb des Uninetzes auf die Server zugegriffen werden. Daher ist es nötig sich entweder vorher über sshgate zu verbinden oder über VPN verbunden zu sein.

Liste der Server im Netz der Fakultät IV (eecsIT)

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 28.04.2022). Falls ihr Abweichungen entdeckt, aktualisiert sie doch bitte.

Auf folgenden Rechnern des eecsIT können sich Studierende mit ihrem tubIT-Account einloggen:

Rechnername Kerne GhZ / Kern RAM OS Release Kommentar
borrasca-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 20.04.4 LTS ubu20
casa-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 20.04.4 LTS ubu20
cascada-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 20.04.4 LTS ubu20
emmerich-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 18.04.6 LTS ubu18
furor-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 18.04.6 LTS ubu18
gata-ubu.eecsit.tu-berlin.de ??? ?,?? ??G ??? ??? Offline
gato-ubu.eecsit.tu-berlin.de ??? ?,?? ??G ??? ??? Offline
kelbassa-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 18.04.6 LTS
kelbassa-ware.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 20.04.4 LTS
kurrat-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 18.04.6 LTS ubu18
tilkowski-ubu.eecsit.tu-berlin.de 16 * Intel Xeon E5-2690 v4 2,60 16G Ubuntu 20.04.4 LTS
toro-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 18.04.6 LTS ubu18
turbador-ubu.eecsit.tu-berlin.de 32 * Intel Xeon E5-2690 v4 2,60 32G Ubuntu 20.04.4 LTS ubu20

Über ubu18.eecsit.tu-berlin.de oder ubu20.eecsit.tu-berlin.de wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18, Ubuntu20), falls mehrere verschiedene vorhanden sind.

sshgate

Desweiteren wird mit sshgate.tu-berlin.de von ZE Campusmanagement Zugriff auf einen RHEL-Server angeboten. Auf diesem System ist außer einfachen Editoren und grundlegender Software kaum weiteres installiert. Jedoch kann es z. B. benutzt werden, um via sshfs einfach Zugriff auf die AFS-Daten zu erhalten, ACLs zu pflegen oder auf TU-interne Dienste zuzugreifen (z.B. SSH auf TU-Server / -Rechner, etc).

Arbeiten auf den Rechnern in der Uni

Das Einloggen funktioniert vom Prinzip her so: 

ssh benutzername@rechnername

oder wenn man sich mit dem Benutzernamen einloggen will, den man gerade verwendet: 

ssh rechnername

Das Ergebnis ist im Allgemeinen eine Shell auf dem angegebenen Rechner mit den Rechten des angegebenen Benutzers.

Als Rechnernamen könnt Ihr alle in der Tabelle oben angegebenen Rechner im Fakultätsnetz verwenden, Ihr müsst nur darauf achten, welche Art von Account ihr besitzt. Alle seit 2009 erstellten Accounts sind in der Regel reine tubit-Accounts.

Windows-SSH-Clients verfügen meist über eine GUI, über die ihr den gewünschten Rechner, Euren Benutzernamen und das Passwort eingeben könnt.

Wenn ihr auf einem Unix/Linux-Rechner (oder auch unter Windows, wenn Ihr einen X-Server installiert habt) arbeitet, besteht auch die Möglichkeit, grafische Programme auf Rechnern in der Uni zu starten und die Ausgabe auf den heimischen Rechner umzuleiten, dies wird als X11-Forwarding bezeichnet.

Grafische Verbindung

Für eine grafische Verbindung gibt es aktuell zwei Möglichkeiten über SSH (neben RDP und VNC): Das etwas ältere X11-Forwarding oder die etwas neuere Variante über x2go.

X2go

Hierzu wird der sog. X2go-Client benötigt, dieser lässt sich für jede Distribution idR. über den Paketmanager installieren (es gibt auch Versionen für Windows und Mac). Der Vorteil von X2go liegt bei der etwas einfacheren Verwendung, auch außerhalb des Uninetzes und einer schnelleren Verbindung der Oberflächen.

X2go bietet sowohl die komplette Anzeige eines Desktops in einem Fenster, ähnlich RDP und VNC, als auch "seamless" angezeigte Fenster, also so ab diese lokal laufen würden.

Im X2Go client einfach folgende Sitzungseinstellungen eintragen: - Sitzungsname: <frei wählen> - Host: Bspw. ubu18.eecsit.tu-berlin.de, siehe obige Tabelle - Proxy-Server aktivieren 

 - Host: sshgate.tu-berlin.de
 - Gleiche Anmeldung wie für X2GO-Server
 - Gleiches Kennwort wie für X2GO-Server

- Sitzungsart: Entweder bspw. "LXDE" für eine vollständige Sitzung mit Desktop, oder "Anwendung" und "xfce4-terminal" für ein Terminal, über das dann entsprechende Programme ("firefox", "gedit", usw.) gestartet werden können.

In den restlichen Tabs muss idR. nichts verändert werden, bei "Ein-/Ausgabe" lässt sich bei Benutzen einer vollständigen Sitzung jedoch die Auflösung/Größe des Desktops und der Vollbildmodus ändern.

X11-Forwarding

Um X11-Forwarding zu aktivieren, muss beim Aufruf der Parameter -X mit angegeben werden. Falls es zu Problemen mit Anwendungen kommt, kann die unsichere Variante -Y verwendet werden. Allerdings werden dadurch serverseitige Befehle, welche die Sicherheit gefährden können, nicht gefiltert. Es empfiehlt sich vor allem bei langsamen Internetzugängen (Modem, ISDN, ADSL), die Verbindung zu komprimieren (-C): 

ssh -X -C benutzer@rechnername
ssh -Y -C benutzer@rechnername

Es empfiehlt sich, aus Sicherheitsgründen immer zuerst das Forwarding mittels -X zu aktivieren - da bei -Y der Zugriff von den Unirechnern auf den Heimischen X-Desktop möglich ist.

Es besteht auch die Möglichkeit, den eigenen Arbeitsplatz nur als X-Terminal zum Uni-Rechnern zu nutzen. Dazu muss man auf dem eigenen Rechner eine X-Session mit nur einem Terminalfenster öffnen. Bei GDM geht das, wenn man als Session "Failsafe Terminal" wählt. Dann verbindet sich man mit X-Forwarding zum Uni-Rechner und feuert gnome-session ab. So wird Java Desktop System erzeugt. Man soll das Terminalfenster mit der gnome-session nicht schließen, solange die Verbindung besteht. Es können auch andere X-Sessions gestartet werden, mit den entsprechenden Befehlen wie z.B. twm, icewm, fvwm. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

Passwortloser Login

Wer keine Lust hat, bei jedem Login ein Passwort einzugeben, kann stattdessen die Kerberos-Authentifizierung (bei ubu**.eecsit.tu-berlin.de-Servern) oder Public-Key-Authentifizierung (bei allen anderen Servern) benutzen.

Kerberos-Authentifizierung

Hinweis: Für die Server mit tubit-Authentifizierung funktioniert die gewohnte Public-Key-Authentifizierung nicht so einfach, da hier das Homeverzeichnis per AFS von ZECM gemounted wird und dazu ein Kerberos-Ticket notwendig ist. Du musst Kerberos/AFS installieren, ein Ticket per 

kinit -f "user"@TU-BERLIN.DE

erzeugen und dann ein paar SSH-Configs setzen: 

ssh "user"@"hostname" -o GSSAPIAuthentication=yes -o GSSAPIDelegateCredentials=yes

Dann sollte der Login ohne Passwortabfrage klappen.

Um diesen Sermon nicht jedesmal neu eingeben zu müssen, kann man sich eine Konfigurationsdatei für ssh anlegen, siehe dazu auch das Beispiel im Absatz SSH#SSH-Optionen_speichern. Auch kann beispielsweise Gnome3 ein solches Ticket erzeugen.

Public-Key-Authentifizierung

Dazu erstellt man, sofern noch nicht geschehen, zu Hause einen öffentlichen und einen privaten Schlüssel für SSH, zum Beispiel mit 

ssh-keygen -t rsa

und leerer Passphrase, kopiert dann die soeben erstellte Datei id_rsa.pub (nicht id_rsa - die ist geheim!) mit scp ins Homeverzeichnis im Fakultätsnetz. Verbindet euch danach per SSH dorthin und führt dort 

cat id_rsa.pub >> .ssh/authorized_keys

aus. Die kopierte Datei kann danach entfernt werden. (Vorsicht: $HOME/.ssh/id_rsa* nicht löschen.)

Lange Prozesse z.B. über Nacht

Manchmal ist es nötig, Prozesse über längere Zeit auf den Servern auszuführen, bspw. Simulationen oder lange Berechnungen ohne den eigenen PC anzulassen, bzw. ständig eingeloggt zu sein. Dies ist allgemein nur eingeschränkt möglich, da die Server aktuell jeden Tag um 06:00 neugestartet werden.

Ein zweites, jedoch umgängliches Problem ist, dass die Server nach dem Ausloggen die Verbindung zum Tubit-AFS getrennt wird, wodurch keine Lese- und Schreibvorgänge auf diesem mehr möglich sind. Darin enthalten sind das Homeverzeichnis des Benutzers und evtl. bereitgestellte Programme der Modulorganisatoren.

Nachfolgend ein Weg, zumindest Prozesse bis zum nächsten Neustart des Servers auszuführen: 

$ pagsh
$ KRB5CCNAME=FILE:`mktemp -p /tmp krb5cc_screen_XXXXXX`
$ kinit -l 1d 
$ aklog
$ screen -S sessionname
  • Nach dem screen-Befehl öffnet sich in dem Fenster eine "leere" Shell. In dieser kann nun der lange Prozess gestartet werden. Empfehlenswert ist es, diesen mit & am Ende zu starten (sowie den Output in eine Logdatei, also command > log.txt 2>&1 &), sodass dieser im Hintergrund gestartet wird. Es wird eine sog. PID ausgegeben, diese sollte sich gemerkt / aufgeschrieben werden, falls ein vorzeitiges Beenden des Prozesses (mit kill) nötig sein sollte. Anschließend lässt sich folgender Befehl ausführen, der eine Erneuerung des Kerberos-Tickets (was nur 10h gültig ist) alle 5h bewirkt:
$ while true; do sleep 18000; krenew; aklog; done;
  • Nachdem nun alle Prozesse laufen, [STRG+A], dann [d] drücken, um die screen-session in den Hintergrund zu schieben
  • Zweimal nacheinander "exit" eingeben (einmal um pagsh zu verlassen, das zweite Mal um die ssh-Verbindung zu schließen). Nun ist die SSH-Verbindung geschlossen, der Prozess wird jedoch weiterlaufen und Zugriff auf das AFS bleibt bestehen.
  • Um nun sich erneut mit der screen-session zu verbinden folgenden Befehl ausführen (nachdem sich mit dem Server verbunden wurde):
$ screen -d -r sessionname
  • Nach getaner Arbeit lassen sich nun noch die Spuren (Kerberostickets) verwischen / löschen mit (in der screen-session ausführen)
$ kdestroy
$ unlog
$ exit
$ exit
$ exit

SSH-Optionen speichern

in der Datei ~/.ssh/config kann man seine Defaults abspeichern. Hier kommt es jetzt sehr darauf an, was man machen möchte.

Wenn man auf seinem Notebook Kerberos installiert hat, und mittels des kinit-Kommandos ein Kerberos Ticket geholt hat, kann man sich an den Servern per Kerberos authentifizieren, die GSSAPI-Optionen werden dazu für das AFS benötigt: 

 Host sshgate.tu-berlin.de, sshgate
   Hostname sshgate.tu-berlin.de
   PubKeyAuthentication no
   User <TUBIT-LOGIN OHNE @-Teil>
   ForwardX11 no
   ForwardAgent no
   PasswordAuthentication yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes
   GSSAPITrustDns yes


Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den Servern nicht möglich, daher benutzt folgende ssh-config Passwort oder Kerberos. In dem zweiten Teil der Config wird auch eine Abkürzung für die ubu18- und ubu20-Server angelegt, sodass nicht die gesamte Domain angegeben werden muss. Außerdem besteht (auskommentiert) die Möglichkeit, den Proxyjump über das sshgate automatisch zu erledigen zu lassen, was die Benutzung eines VPNs erspart. 

 Host ubu18
   Hostname ubu18.eecsit.tu-berlin.de
 Host ubu20
   Hostname ubu20.eecsit.tu-berlin.de
 Host *.eecsit.tu-berlin.de *.hpc.tu-berlin.de unu18 ubu20
   PubKeyAuthentication no
   User <TUBIT-LOGIN OHNE @-Teil>
   ForwardX11 no
   ForwardAgent no
   PasswordAuthentication yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials yes
   GSSAPITrustDns yes
   #ProxyJump sshgate.tu-berlin.de

Da man den SSH-Servern nicht 100% vertrauen sollte, werden in mit Config keine ssh-agent-Anfragen an den lokalen Agenten weitergeleitet und auch kein X-Forwarding erlaubt. Das kann man auf der Kommandozeile im konkreten Fall alles überschreiben, aber die Defaults sollen 'sicher' sein.

Kopieren von Dateien

Mit Hilfe von scp oder sftp könnt Ihr auch Dateien von der Uni nach Hause kopieren oder umgekehrt. Für Windows und auch Unix/Linux gibt es dafür grafische Programme, die ähnlich wie gewöhnliche FTP-Clients aussehen und funktionieren. Viele FTP-Programme beherrschen mittlerweile auch SFTP, darunter auch FileZilla, gFTP etc.

GNOME und KDE bieten außerdem die Möglichkeit, direkt auf SSH-Accounts mittels der Dateiverwaltung (Nautilus/Konqueror) zuzugreifen. Der URL dazu lautet: sftp://BENUTZERNAME@ubu20.eecsit.tu-berlin.de:22/~ (Alternativ das sshgate, wobei ubu18 jedoch die Möglichkeit bietet unter z.B. Gnome mit Rechtsklick direkt ein funktionierendes Terminal mit allen Tools zu öffnen).

Mit Hilfe von FUSE kann man die Daten eines anderen Rechners auch per ssh/sftp mounten, das heißt ins lokale Dateisystem einhängen.

Auf der Konsole unter Unix/Linux funktioniert das Kopieren von Dateien so (Kopieren von entferntem auf lokalen Rechner): 

scp benutzername@rechnername:Quelle Ziel

oder umgekehrt (von lokalem Rechner auf entfernten): 

scp Quelle benutzername@rechnername:Ziel

Es gilt im Wesentlichen die Semantik von cp.

Natürlich ist es auch möglich mehrere Dateien oder ganze Verzeichnisse einschließlich Unterverzeichnissen (rekursiv) oder Dateien zwischen verschiedenen entfernten Rechnern zu kopieren. Weitere Informationen dazu erhält man über die Manpage zu scp (man scp).

Tunnel mit SSH

SSH kann auch allgemein eine Verbindung zu einem entfernten Rechner herstellen und als Tunnel agieren, also Daten zwischen eigenem und entferntem Rechner transportieren. Dazu zwei Beispiele.

Ein Nachteil von SSH-Tunnels ist, dass sie im Vergleich zu direkten Verbindungen einen Ressourcenoverhead hinzufügen. Deshalb sollten sie genau dann benutzt werden, wenn die zusätzliche Funktionalität tatsächlich benötigt wird.

SSH als SOCKS-Proxy

Seit einiger Zeit ist der ssh-Client auch in der Lage, als socks-Proxy zu fungieren.

Dazu starte man ihn mit der Option -D8080 und gebe als SOCKS-Proxy localhost und port 8080 an. Die Felder zu HTTP/FTP-Proxy in der Konfiguration des Lieblingsbrowsers bleiben dabei leer: 

ssh -D 8080 login@ubu18.tu-berlin.de

Portforwarding mit SSH

SSH ist in der Lage entweder einen entfernten Port zum lokalen Rechner zu forwarden (bspw. ein entferntes Jupyternotebook was dann lokal im Browser geöffnet werden kann) oder eine lokalen Port zu einem Server zu transportieren (bspw. angeschlossene FPGAs an den lokalen Rechner, lediglich mit dem sehr viel ressourcenfreundlicheren Xilinx Hardwaremanager, worauf mit dem entfernt laufenden Xilinx Vivado zugegriffen wird).

Für ersteren Fall (erste Portnummer für lokal (der zu öffnende), zweite für remote (der bereits existierende Port)): 

 ssh -L 8080:remote-server:8080 remote-server

Für zweiteren Fall (erste Portnummer für remote (der zu öffnende), zweite für lokal (der bereits existierende Port)): 

 ssh -R 3121:localhost:3121 remote-server

Im zweiten Fall ist jedoch beachten, dass man für Ports <1024 root-Rechte benötigt.

Weblinks

Abgerufen von „https://wiki.freitagsrunde.org/index.php?title=SSH&oldid=25036“