FreitagsrundenWiki - Benutzerbeiträge [de]

SSH

2022-04-28T16:22:16Z

Freddy1404: Update Server

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit 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:

{| class="wikitable"
|- class="hintergrundfarbe5"
! 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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 ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-02-04T22:39:08Z

Freddy1404: typo

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 05.02.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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 ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-02-04T22:38:46Z

Freddy1404: Outdated info entfernt, Port forwarding weil nützlich mal hinzugefügt.

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 05.02.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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:renote-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 ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-02-04T22:28:07Z

Freddy1404: keine ahnung mehr, was ich hier aktualisiert habe

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 05.02.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-02-04T22:25:08Z

Freddy1404: sftp Domain updated, added hint for sshgate

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 01.01.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.3 LTS || ubu20
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-02-04T22:24:24Z

Freddy1404: Updated config details for new servers only, removed outdated info

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 01.01.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.3 LTS || ubu20
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-01-01T19:21:40Z

Freddy1404: casa is ubu20 now, formatted table

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 01.01.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.3 LTS || ubu20
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-01-01T17:56:18Z

Freddy1404: casa is ubu20 now

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 01.01.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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.3 LTS || ubu20
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-01-01T17:30:28Z

Freddy1404: Updated config details for new servers only, removed outdated info

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 no

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

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-01-01T17:30:00Z

Freddy1404: sftp Domain updated, added hint for sshgate

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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@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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2022-01-01T17:27:57Z

Freddy1404: Updated config details for new servers only, removed outdated info

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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 no

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

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2021-10-04T23:01:23Z

Freddy1404:

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2021-10-04T23:01:06Z

Freddy1404: kelbassa-ware hinzugefügt

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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.3 ||
|-
|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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2021-10-04T22:51:36Z

Freddy1404: Tabelle aktualisiert

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.6 LTS || ubu18
|-
|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 || ??? || ?,?? || ??G || ??? || ??? || No permission
|-
|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.3 LTS || ubu20
|-
|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.3 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'' [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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2021-01-18T10:49:53Z

Freddy1404: kelbassa-ubu works again

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 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.5 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || No permission
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16, ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16
|-
|}

Ü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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2021-01-04T22:03:24Z

Freddy1404: Stand => today

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 04.01.2021). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || No permission
|-
|kelbassa-ware.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || No permission
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16, ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16
|-
|}

Ü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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2021-01-04T22:02:18Z

Freddy1404: Removed kelbassa-x, Message after login:"This account is not available for this server. https://www.eecs.tu-berlin.de/eecsit/v/dienste/externer_zugriff"

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 27.10.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || No permission
|-
|kelbassa-ware.eecsit.tu-berlin.de || ??? || ?,?? || ??G || ??? || ??? || No permission
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16, ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16
|-
|}

Ü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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-11-15T20:32:54Z

Freddy1404: x2go hinzugefügt

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 27.10.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ---
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.1 LTS || ---
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16, ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16
|-
|}

Ü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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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. [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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-10-27T14:44:29Z

Freddy1404: Text aktualisierung

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 27.10.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ---
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.1 LTS || ---
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16, ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16
|-
|}

Ü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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-10-27T14:43:24Z

Freddy1404: Server aktualisiert

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 27.10.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ---
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 20.04.1 LTS || ---
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.5 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16, ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 32G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu16
|-
|}

Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' (neu, aktuell nur ''kelbassa-ware'' mit Ubuntu 18) wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18), 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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-10-27T14:30:23Z

Freddy1404: tilkowski aktualisiert

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 30.04.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ---
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu20
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 16G || Ubuntu || 20.04.1 LTS || ubu20
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.4 LTS || ubu16
|-
|}

Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' (neu, aktuell nur ''kelbassa-ware'' mit Ubuntu 18) wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18), 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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-04-30T12:51:06Z

Freddy1404: Sammeldomain hinzugefügt, gata und gato als Offline unbekannt eingetragen

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 30.04.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ---
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu20
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|tilkowski-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || ubu16, Offline
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS || ubu18
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.4 LTS || ubu16
|-
|}

Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' (neu, aktuell nur ''kelbassa-ware'' mit Ubuntu 18) wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18), 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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-04-30T11:47:41Z

Freddy1404: /* Liste der Server im Netz der Fakultät IV (eecsIT) */

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 10.04.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|gato-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS || Offline
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|tilkowski-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Offline
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.4 LTS ||
|-
|}

Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' (neu, aktuell nur ''kelbassa-ware'' mit Ubuntu 18) wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18), 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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-04-09T23:13:09Z

Freddy1404: Link zu eecsit-Seite hinzugefügt

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [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.

'''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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 10.04.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|gato-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS || Online, jedoch ssh Timeout
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|tilkowski-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.4 LTS ||
|-
|}

Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' (neu, aktuell nur ''kelbassa-ware'' mit Ubuntu 18) wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18), 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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2020-04-09T23:08:07Z

Freddy1404: Server nur noch aus dem Uninetz erreichbar, Struktur verbessert, Fehler verbessert, Tilkowski hinzugefügt

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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 [[SSH#sshgate|sshgate]] zu verbinden oder über [[VPN|VPN]] verbunden zu sein.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 10.04.2020). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|gato-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS || Online, jedoch ssh Timeout
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|tilkowski-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.4 LTS ||
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.4 LTS ||
|-
|}

Über ''ubu18.eecsit.tu-berlin.de'' oder ''ubu20.eecsit.tu-berlin.de'' (neu, aktuell nur ''kelbassa-ware'' mit Ubuntu 18) wird auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu18), 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 ===
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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

==== 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>):
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 <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.

==== 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:
* 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 ===

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
User <TUBIT-LOGIN OHNE @-Teil>
ForwardAgent no
ForwardX11 no
PasswordAuthentication no
PubKeyAuthentication no
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen Servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2019-10-31T18:13:47Z

Freddy1404:

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 11.10.2019). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|gato-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS ||
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS ||
|-
|}

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

Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von tubIT] Zugriff auf einen RHEL-Server angeboten. Auf diesem System 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).

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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]].

==== 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:
* 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 ===

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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2019-10-11T09:26:41Z

Freddy1404: /* Liste der Server im Netz der Fakultät IV (eecsIT) */

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 11.10.2019). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|gata-ubu.eecsit.tu-berlin.de || ??? || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|gato-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS || Online, jedoch ssh Timeout
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS ||
|-
|}

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

Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von tubIT] Zugriff auf einen RHEL-Server angeboten. Auf diesem System 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).

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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]].

==== 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:
* 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 ===

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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2019-10-11T09:26:02Z

Freddy1404: Added turbador, kelbassa-ware and gata. Updated Ubuntu version. Added comment field

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 11.10.2019). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release !! Kommentar
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|gata-ubu.eecsit.tu-berlin.de || ?? * Intel Xeon E5-2690 v4 || ?,?? || ??G || Ubuntu || ??? || Online, jedoch ssh Timeout
|-
|gato-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS || Online, jedoch ssh Timeout
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|kelbassa-ware.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.3 LTS ||
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,60 || 15G || Ubuntu || 18.04.3 LTS ||
|-
|}

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

Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von tubIT] Zugriff auf einen RHEL-Server angeboten. Auf diesem System 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).

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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]].

==== 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:
* 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 ===

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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2018-12-01T16:08:36Z

Freddy1404: /* Liste der Server im Netz der Fakultät IV (eecsIT) */

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 01.12.2018). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|}

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

Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von tubIT] Zugriff auf einen RHEL-Server angeboten. Auf diesem System 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).

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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]].

==== 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:
* 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 ===

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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2018-12-01T16:08:18Z

Freddy1404: /* Liste der Server im Netz der Fakultät IV (eecsIT) */

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 26.05.2018). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release
|-
|borrasca-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,60 || 31G || Ubuntu || 18.04.1 LTS
|-
|}

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

Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von tubIT] Zugriff auf einen RHEL-Server angeboten. Auf diesem System 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).

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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]].

==== 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:
* 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 ===

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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

Einführungswoche 2018

2018-10-08T09:21:16Z

Freddy1404: Rechnereinführung am 12.10 ist für alle Studiengänge

'''[[#Programme (english)|English version below!]]'''






Die Einführungswoche 2018 findet vom 8. bis 12. Oktober statt. Bitte beachtet, dass sich Räume noch ändern können und guckt kurz vorher noch mal rein.<br />
Eine kurze Liste mit Dingen, die man brauchen oder nicht brauchen kann findest du im Beitrag [[StarterPaket | Starter-Paket]].<br />
Wenn du nicht an allen Tagen kommen kannst, solltest du versuchen, wenigstens am Dienstag zu kommen.

The orientation week 2018 takes place from 8th to 12th october. Please bear in mind that rooms might change and check again shorter to the date.<br />
If you can't make it to all of the events you should try to come at least on tuesday.

=== Programm ===
Das Programm ist auch [http://www.eecs.tu-berlin.de/menue/studium_und_lehre/start_ins_studium/semesterbeginn/ewoche/alle_tage/ auf den Fakultätswebseiten] verfügbar.
==== Donnerstag, 04.10.2018 und Freitag, 05.10.2018 ====
Einführung für ausländische Studierende: [https://www.ziik.tu-berlin.de/menue/ziik/veranstaltungen/2018/veranstaltungen_fuer_auslaendische_neuimmatrikulierte_der_fakultaet_iv/ Programm] -->

==== Montag, 08.10.2018 ====
Am Montag geht es los mit der Einführungswoche der TU Berlin.
* Raum ist HE 101, welcher sich im Mathe-Gebäude befindet.
* Ab 11 Uhr (s.t.) findet die Begrüßung durch das Dekanat statt. Dort werden auch die Erstitüten verteilt, welche das gesammelte Infomaterial enthalten.

==== Dienstag, 09.10.2018 ====
Ab Dienstag geht es dann mit dem fakultätsspezifischen Programm weiter.
* Vortrag ''How TU Studium''
** 10 bis 12 Uhr
** Bachelor Elektrotechnik: H 1058
** Bachelor Informatik: MA 004
** Bachelor Medieninformatik: MA 004
** Bachelor Medientechnik: MA 005
** Bachelor Technische Informatik: MA 005
** Bachelor Wirtschaftsinformatik: H 1058
* Einführung in die Studiengänge mit anschließenden Kleingruppentutorien
** Dabei werden auch die Stundenpläne und Studiengangsführer verteilt
** 12 bis 15 Uhr
** Bachelor Elektrotechnik: MA 005
** Bachelor Informatik: MA 001
** Bachelor Medieninformatik: MAR 0.011
** Bachelor Medientechnik: H 0107
** Bachelor Technische Informatik: EW 201
** Bachelor Wirtschaftsinformatik: H 1058
* Einführung in die Masterstudiengänge mit anschließenden Kleingruppentutorien
** 14 bis 17 Uhr
** Master Computer Science (Informatik): H 2013
** Master Computer Engineering (Technische Informatik): BH-N 334
** Master Information Systems Management (Wirtschaftsinformatik): BH-N 128
** Master Elektrotechnik: HFT-TA 101
** Master Automotive Systems: H 0107
** Master Medieninformatik: MAR 4.062
** Master Computational Neuroscience: Am Montag, 15. Oktober von 10 bis 12 Uhr im Bernstein Center for Computational Neuroscience
* Masterstammtisch
** 20 Uhr im Café Hardenberg

==== Mittwoch, 10.10.2018 ====
* Ersti-Frühstück für Studentinnen* im Raum MAR 0.011
** 8:30 bis 10:00
** mit der [https://www.eecs.tu-berlin.de/frauenbeauftragte/v_menue/frauenbeauftragte/ Frauenbeauftragten der Fakultät IV]
* Studieren und mehr
** 10 bis 12 Uhr in den Räumen MA 001 und H 0104
** Was kann man außer Studieren sonst noch machen.
* Lötworkshop „Löten & Kennenlernen“ (12 Teilnehmerinnen*)
** 14 bis 18 Uhr
** Angebot der Frauenbeauftragten der Fakultät IV, [https://www.eecs.tu-berlin.de/frauenbeauftragte/v_menue/frauenbeauftragte/aktuelles/ weitere Infos]
** E-N 201, '''vorherige Anmeldung erforderlich''' (siehe Link)
* Kickerturnierplanung
** 17 bis 19 Uhr
** MAR 0.007
** Das Kickerturnier findet am 23. November statt.

==== Donnerstag, 11.10.2018 ====
* Frühstück
** 10 Uhr bis 13 Uhr im Foyer des MAR-Gebäudes (Erdgeschoss)
** mit Brötchen, Kaffee und Infocampus
* Unirallye
** 13 bis 16 Uhr auf dem Campus Charlottenburg
* Lötworkshop „Löten & Kennenlernen“ (12 Teilnehmerinnen*)
** 14 bis 18 Uhr
** Angebot der Frauenbeauftragten der Fakultät IV, Fortsetzung vom Mittwoch
* Vorstellung des [http://www.loetlabor.de Lötlabors], der Amateurfunkgruppe [http://www.dk0tu.de DK0TU] (alle 30 Minuten) und der Vereinigung [https://digitale-freiheit.jetzt/ Digitale Freiheit]
** 16 bis 18 Uhr
** Lötlabor: EN 444/445
** DK0TU: Hauptgebäude - Foyer
** Digitale Freiheit: AStA-Plenarium im TK-Gebäude
* Ersti-Party Orga-Treffen
** 18 bis 20 Uhr im MAR 0.007
** Organisation einer Party von Erstsemestern für Erstsemester am 19.10.2018

==== Freitag, 12.10.2018 ====
* Programmieren mit C: ein Workshop für Einsteigerinnen (25 Teilnehmerinnen*)
** 9 bis 12 Uhr
** Angebot der Frauenbeauftragten der Fakultät IV, [https://www.eecs.tu-berlin.de/frauenbeauftragte/v_menue/frauenbeauftragte/aktuelles/ weitere Infos]
** MAR 6.057, '''vorherige Anmeldung erforderlich''' (siehe Link)
* Rechnereinführung für <del>ET und WiInf</del> alle Studiengänge der Fak. IV
** 10 bis 12 Uhr im TEL 106 links und rechts (großer Rechnerraum)
* Freitagsrunde für alle
** 14 bis 18 Uhr
** MAR 0.016
** Gebt uns euer Feedback zur E-Woche :)

==== Montag, 15.10.2018 ====
* Einführungsveranstaltung Masterstudiengang Computational Neurosceince
** 10 bis 12 Uhr im Bernstein Center for Computational Neuroscience (BCCN), Haus 6, Hörsaal 9, Philippstr. 13, 10115 Berlin

Nach der eigentlichen E-Woche gibt es noch weitere Veranstaltungen.
Diese werden dann hier angekündigt.

* Ersti-Party (19.10.2018)
* LIP aka Linux Install Party (02.11.2018)
* Kickerturnier (23.11.2018)

=== Programme (english) ===

You can also find this [http://www.eecs.tu-berlin.de/menue/studium_und_lehre/start_ins_studium/semesterbeginn/ewoche/alle_tage/ programme on the university website].

==== Thursday, 04.10.2018 and Friday, 05.10.2018 ====
Introduction for international students: [https://www.ziik.tu-berlin.de/menue/ziik/veranstaltungen/2018/veranstaltungen_fuer_auslaendische_neuimmatrikulierte_der_fakultaet_iv/ Schedule]

==== Monday, 08.10.2018 ====
The orientation week starts on monday.
* Faculty IV introduction - welcome adress by the dean of studies [in German]
** 11 to 12 o'clock at the HE 101 (Mathe-Building)
** followed by the distribution of the firstsemester paper bags with collected information leaflets

==== Tuesday, 09.10.2018 ====
The faculty programme starts on tuesday.
* How TU Studium
** 10 to 12 o'clock
** Bachelor Elektrotechnik: H 1058
** Bachelor Informatik: MA 004
** Bachelor Medieninformatik: MA 004
** Bachelor Medientechnik: MA 005
** Bachelor Technische Informatik: MA 005
** Bachelor Wirtschaftsinformatik: H 1058
* Introduction to the bachelor degrees followed by small group tutorials
** 12 to 15 o'clock
** Bachelor Elektrotechnik: MA 005
** Bachelor Informatik: MA 001
** Bachelor Medieninformatik: MAR 0.011
** Bachelor Medientechnik: H 0107
** Bachelor Technische Informatik: EW 201
** Bachelor Wirtschaftsinformatik: H 1058
* Introduction into the master degrees followed by small group tutorials
** 14 to 17 o'clock
** Master Computer Science (Informatik): H 2013
** Master Computer Engineering (Technische Informatik): BH-N 334
** Master Information Systems Management (Wirtschaftsinformatik): BH-N 128
** Master Elektrotechnik: HFT-TA 101
** Master Automotive Systems: H 0107
** Master Medieninformatik: MAR 4.062
** Master Computational Neuroscience: Monday, 15. October from 10 to 12 o'clock at the Bernstein Center for Computational Neuroscience
* Masters social evening
** 20 o'clock at the Cafè Hardenberg

==== Wednesday, 10.10.2018 ====
* Breakfast for female* students
** 8:30 to 10 o'clock at MAR 0.011
* Studieren und mehr [in German]
** 10 to 12 o'clock at H 0104 and MA 001
** What can you do at TU Berlin besides studying.
* Solderingworkshop „Löten & Kennenlernen“ for women (12 participants)
** 14 to 18 o'clock
** Offering from the womens representative of Faculty IV, [https://www.eecs.tu-berlin.de/frauenbeauftragte/v_menue/frauenbeauftragte/aktuelles/ further information]
** E-N 201, '''prior registration required''' (see link)
* Presentation of the [http://www.loetlabor.de Lötlabor] student lab, the amateur radio operators student group [http://www.dk0tu.de DK0TU] (every 30 minutes) and the community [https://digitale-freiheit.jetzt/ Digitale Freiheit]
** 16 to 18 o'clock
** Loetlabor: EN 444/445
** DK0TU: Hauptgebäude (main building) - foyer
* Table Football Tournament Organizational Meeting
** 17 to 19 o'clock at MAR 0.007
** The tournament is taking place friday, the xxth of november

==== Thursday, 11.10.2018 ====
* Breakfast
** 10 to 13 o'clock on the MAR groundfloor
* Unirallye
** 13 to 18 o'clock on the campus
* Solderingworkshop „Löten & Kennenlernen“ for women (12 participants)
** 14 to 18 o'clock
** Offering from the womens representative of Faculty IV, continued from Wednesday
* First-Semester-Party-Organization Meeting
** 18 to 20 o'clock at MAR 0.007
** first semesters organize a party for first semesters. The party is one week later on the 19.10.2017.

==== Friday, 12.10.2018 ====
* Programmieren mit C: ein Workshop für Einsteigerinnen (Coding with C, a workshop for beginners, for women)(25 participants)
** 9 bis 12 Uhr
** Offering from the womens representative of Faculty IV, [https://www.eecs.tu-berlin.de/frauenbeauftragte/v_menue/frauenbeauftragte/aktuelles/ further information]
** MAR 6.057, '''prior registration required''' (siehe Link)
* Introduction to the IT systems and services for <del>electrical engineering and information systems managment students</del> all students of Faculty IV
** 10 to 12 o'clock at TEL 106 left and right
* Freitagsrunde for everybody
** 14 to 18 o'clock at MAR 0.016

==== Monday, 15.10.2018 ====
* Introduction course for the masters programme Computational Neurosceince
** 10 to 12 o'clock at the Bernstein Center for Computational Neuroscience (BCCN), House 6, Hall 9, Philippstr. 13, 10115 Berlin

There are more events after the orientation week.

* Campus Party (19.10.2018)
* LIP: Linux Install Party (02.11.2018)
* table football tournament (23.11.2018)

[[Kategorie: Einführungswoche]]

SSH

2018-05-26T00:52:11Z

Freddy1404: kelbassa added, text formatting, sshgate update

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 26.05.2018). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! GhZ / Kern !! RAM !! OS !! Release
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|borrasca-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || 2,6 || 15G || Ubuntu || 16.04.4 LTS
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || 2,4 || 15G || Ubuntu || 16.04.4 LTS
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || 2,4 || 15G || Ubuntu || 16.04.4 LTS
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || 2,4 || 15G || Ubuntu || 16.04.4 LTS
|-
|}

Über ''ubu16.eecsit.tu-berlin.de'' und ''ubu18.eecsit.tu-berlin.de'' wird (durch round robin DNS) auf einen der obigen Server umgeleitet, der mit der entsprechenden Ubuntu-Version läuft (Ubuntu16, Ubuntu18).

Desweiteren wird mit ''sshgate.tu-berlin.de'' [http://www.tubit.tu-berlin.de/?id=53313 von tubIT] Zugriff auf einen RHEL-Server angeboten. Auf diesem System 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).

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2018-05-24T20:37:28Z

Freddy1404: Tabelle aktualisiert, nicht mehr erreichbare Server gelöscht, Text leicht aktualisiert

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 24.05.2018). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! Threads !! GhZ / Kern !! RAM !! OS !! Release
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|toro-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E5-2690 v4 || || 2,6 || 31G || Ubuntu || 18.04 LTS
|-
|borrasca-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E5-2690 v4 || || 2,6 || 15G || Ubuntu || 16.04.4 LTS
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04.4 LTS
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04.4 LTS
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04.4 LTS
|-
|}

Über ubu16.eecsit.tu-berlin.de und ubu18.eecsit.tu-berlin.de wird (nach Last?) auf einen der obigen Server umgeleitet, die mit der entsprechenden Ubuntu-Version laufen (Ubuntu16, Ubuntu18).

Desweiteren wird mit sshgate.tu-berlin.de [http://www.tubit.tu-berlin.de/?id=53313 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)

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2017-10-10T23:40:52Z

Freddy1404: Stand hinzugefügt

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden (Aktueller Stand: 11.10.2017). 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="hintergrundfarbe5"
! Rechnername !! Kerne !! Threads !! GhZ / Kern !! RAM !! OS !! Release
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|gato-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|gata-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 14.04
|-
|borrasca-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|kelbassa-ware.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|toro-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|}

Über ubu14.eecsit.tu-berlin.de und ubu16.eecsit.tu-berlin.de wird (nach Last?) auf Server umgeleitet, die entsprechende Ubuntu-Versionen haben (Ubuntu14, Ubuntu16).

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)

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2017-10-10T23:38:29Z

Freddy1404: borrasca umsortiert

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden. 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="hintergrundfarbe5"
! Rechnername !! Kerne !! Threads !! GhZ / Kern !! RAM !! OS !! Release
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|gato-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|gata-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 14.04
|-
|borrasca-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|kelbassa-ware.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|toro-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|}

Über ubu14.eecsit.tu-berlin.de und ubu16.eecsit.tu-berlin.de wird (nach Last?) auf Server umgeleitet, die entsprechende Ubuntu-Versionen haben (Ubuntu14, Ubuntu16).

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)

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2017-10-10T23:03:12Z

Freddy1404: RAM hinzugefügt, Liste gecheckt, ubu14&16 hinzugefügt

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im Netz der Fakultät IV ([http://www.eecs.tu-berlin.de/eecsit eecsIT]) ===

Achtung, diese Liste kann nur schwer aktuell gehalten werden. 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="hintergrundfarbe5"
! Rechnername !! Kerne !! Threads !! GhZ / Kern !! RAM !! OS !! Release
|-
|borrasca-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|casa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|cascada-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|emmerich-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|gato-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|gata-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 31G || Ubuntu || 14.04
|-
|kelbassa-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 14.04
|-
|furor-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|kelbassa-ware.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|kurrat-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|tilkowski-ubu.eecsit.tu-berlin.de || 32 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|toro-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|turbador-ubu.eecsit.tu-berlin.de || 16 * Intel Xeon E7- 4870 || || 2,4 || 15G || Ubuntu || 16.04
|-
|}

Über ubu14.eecsit.tu-berlin.de und ubu16.eecsit.tu-berlin.de wird (nach Last?) auf Server umgeleitet, die entsprechende Ubuntu-Versionen haben (Ubuntu14, Ubuntu16).

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)

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

Diskussion:SSH

2016-10-17T20:42:05Z

Freddy1404: Neuer Abschnitt /* Liste der Server */

Koennte der Mensch, der die @-Zeichen umgestellt hat, bitte den Grund
erklaeren? Laut ssh-/scp-Manpages werden die naemlich genau dann benoetigt,
wenn man sowohl den Benutzer- als auch den Rechnernamen in der
foo@bar-Syntax angibt. Da man fast immer mindestens den Rechnernamen
angeben will, ist das @-Zeichen also nur dann noetig, wenn man auch einen
Benutzernamen angibt, daher die Schreibweise in der
[https://wiki.freitagsrunde.org/index.php?title=SSH&oldid=5722 alten Version]. --[[Benutzer:Estar|estar]] 13:58, 7. Jul 2005 (CEST)

== Windows Terminal Server ==
siehe [[Windows Terminal Server]]

== Vorschlag: SSH-Beispiele umstellen auf Tubit-Account-Kompatibilität ==
Ich würde die konkreten Beispiele, wo fiesta und bolero verwendet wird demnächst mal umstellen auf Hosts, bei denen ein Login per Tubit möglich ist, da seit 2008 eh keine IRB-Accounts mehr an Verteilt werden und so die Erfolgswahrscheinlichkeit für Neulinge die die Beispiele direkt testen höher ist.--[[Benutzer:Stefan|Stefan]] 02:35, 24. Feb. 2010 (CET)

: Find ich cool - würde aber vorschlagen dazu oben nen neuen Block einzufügen - also nicht nur 'umstellen' sondern hinzufügen :) Komm doch mal Freitag vorbei... Ich geb Dir 'ne Mate aus! --[[Benutzer:Mutax|Florian]] 12:17, 24. Feb. 2010 (CET)

== Sicheres X11Forwarding ==
Das mit der angeblich sichereren Option shh -Y steht hier zwei mal genau falsch herum drin. Deswegen aender ich das jetzt. Sicherer ist -X! -Y ist fuer trusted X11Forwarding in diesem Fall wird dem Server vertraut. -X dagegen schraenkt Zugriffe ein. Quellen: manpages und [http://dailypackage.fedorabook.com/index.php?/archives/48-Wednesday-Why-Trusted-and-Untrusted-X11-Forwarding-with-SSH.html Trusted-and-Untrusted-X11-Forwarding-with-SSH] --[[Benutzer:Phil|Phil]] 03:18, 29. Aug. 2011 (CEST)

== Erreichbarkeit ==
quepasa und torero sind nicht erreichbar? oder stell ich mich zu bloed an? --[[Benutzer:JonWon|JonWon]] 15:21, 21. Okt. 2011 (CEST)

== cpu info auf den Solaris Rechnern ==

Damit ich nicht vergesse, wie man unter Solaris die Anzahl der Prozessoren und Threads herausfinden kann.

Anzahl der Prozessoren:
kstat cpu_info | grep core_id | uniq | wc -l

Anzahl der Threads:
kstat cpu_info | grep core_id | wc -l

== Liste der Server ==

Hallo,

ich habe mal die Ubuntu-Versionen aktualisert, sowie die Kerne und die Liste mal alphabetisch und nach Ubuntu-Version sortiert. Ebenso den emmerich-ubu.eecsit.tu-berlin.de hinzugefügt.

Ich war nur leicht verwundert, dass die Liste bereits in dem Format n * Prozessor war, da dies meist ja nur Kerne sind und keine eigenständigen Prozessoren. Die Anzahl an Sockets schwangt zwischen zwei und vier, es gibt ebenso Server denen vier Kerne / Socket zugewiesen waren, mal 16 Kerne / Socket. Ist diese Info wichtig (Anzahl Sockets, Anzahl Kerne) oder könnte sie eigentlich auch rausgelassen werden?

SSH

2016-10-17T20:38:13Z

Freddy1404: falsche Kernezahl

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im CS-Netz ===

Achtung, die Liste hier ist nicht mehr aktuell. Insbesondere stimmt die Kern/Thread Anzahl oft nicht mehr.

Auf folgenden Rechnern des IRB können sich Studenten einloggen:

{| class="wikitable"
|- class="hintergrundfarbe5"
! Rechnername !! tubit-Account !! CS-Account !! Kerne !! Threads !! GhZ / Kern !! OS !! Release
|-
|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 ||
|-
|caramba.cs.tu-berlin.de || nein || ja || || || || SunOS ||
|-
|borrasca-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|casa-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|cascada-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|emmerich-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|gato-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|gata-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|kelbassa-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|furor-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|kelbassa-ware.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|kurrat-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|tilkowski-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|toro-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|turbador-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|}

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)

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]

SSH

2016-10-17T20:31:00Z

Freddy1404: /* Liste der Server im CS-Netz, Ubuntu versionen aktualisiert, Kerne aktualisiert */

'''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: <code>ssh</code>, <code>scp</code>, <code>sftp</code>). Für [[Windows]]-Systeme gibt es ebenfalls einige SSH-Clients, am häufigsten wird wohl [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] verwendet.

Ein SFTP und SCP-Client zum Kopieren von Dateien über das Netzwerk ist ebenfalls bei [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY] vorhanden. [http://winscp.sourceforge.net/eng/ 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.

=== Liste der Server im CS-Netz ===

Achtung, die Liste hier ist nicht mehr aktuell. Insbesondere stimmt die Kern/Thread Anzahl oft nicht mehr.

Auf folgenden Rechnern des IRB können sich Studenten einloggen:

{| class="wikitable"
|- class="hintergrundfarbe5"
! Rechnername !! tubit-Account !! CS-Account !! Kerne !! Threads !! GhZ / Kern !! OS !! Release
|-
|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 ||
|-
|caramba.cs.tu-berlin.de || nein || ja || || || || SunOS ||
|-
|borrasca-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|casa-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|cascada-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|emmerich-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|gato-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|gata-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|kelbassa-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 14.04
|-
|furor-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|kelbassa-ware.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|kurrat-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|tilkowski-ubu.eecsit.tu-berlin.de || ja || nein || 32 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|toro-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|turbador-ubu.eecsit.tu-berlin.de || ja || nein || 16 * Intel Xeon E7- 4870 || || 2,4 || Ubuntu || 16.04
|-
|}

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)

=== 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 Allgemeneinen 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 [https://secure.wikimedia.org/wikipedia/de/wiki/Grafische_Benutzeroberfl%C3%A4che 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.

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 -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, 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,
z.B. <code>twm, icewm, fvwm</code>. Die Verbindung sollte dann allerdings etwas besser sein, da größere Datenmengen übertragen werden.

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
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.)

==== Authentifizierung ohne Passwort auf den neuen Servern ====
'''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
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 Konfigurationsdetei für ssh anlegen, siehe dazu ach das Beispiel im folgenden Absatz.

=== 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 authentifiziren, die GSSAPI-Optionen werden dazu für das AFS benötigt:

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

Durch die Verwendung von AFS ist das Anmelden mit ssh-keys auf den neuen servern nicht mehr möglich, folgende ssh-config benutzt keys für die alten Server und Passwort oder Kerberos für die neuen inklusive dem sshgate von tubit.

Host bolero.cs.tu-berlin.de fiesta.cs.tu-berlin.de bird.cs.tu-berlin.de caramba.cs.tu-berlin.de cartero.cs.tu-berlin.de bruja.cs.tu-berlin.de brujo.cs.tu-berlin.de pepita.cs.tu-berlin.de pepino.cs.tu-berlin.de condesa.cs.tu-berlin.de bonito.cs.tu-berlin.de caro.cs.tu-berlin.de
PubKeyAuthentication yes
PasswordAuthentication no
User mutax
IdentityFile ~/.ssh/keys/id_rsa3
ForwardAgent no
ForwardX11 no

Host sshgate.tu-berlin.de 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 furor.cs.tu-berlin.de cascada.cs.tu-berlin.de turbador.cs.tu-berlin.de racha.cs.tu-berlin.de torero.cs.tu-berlin.de
PubKeyAuthentication no
User mutax
ForwardAgent no
ForwardX11 no
PasswordAuthentication yes
GSSAPIAuthentication yes
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.

=== 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 [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>.

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.

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 <code>[[Die wichtigsten Unix-Befehle#cp|cp]]</code>.

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

=== 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.

==== Zugriff auf <code>news.cs.tu-berlin.de</code> von zu Hause ====
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).
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 ====

Dies wird in einem eigenen Artikel beschrieben: [[Email]]

==== Zugriff auf Webseiten mit IP-Adressen-Zugriffsbeschränkung ====
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 ====

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@bolero.cs.tu-berlin.de

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.

== Weblinks ==
* http://www.openssh.com/
* http://www.ssh.com/
* http://www.chiark.greenend.org.uk/~sgtatham/putty/
* http://www.cygwin.com/ - Eine Sammlung auf Windows portierter Unix-typischer freier Software, inklusive X-Server und ssh.

[[Kategorie: Fachbegriffe der Informatik]]
[[Kategorie: Fakultäts-ABC]]
[[Kategorie: Überleben im Fakultätsnetz]]