SSH (Secure Shell)

SSH bietet einen sicheren (da verschlüsselten) Zugang zu einem entfernten Rechner/Server. Es ist deshalb sicher weil die Verbindung mit starker Verschlüsselung gesichert wird und sich beide Partner ausweisen (Authentifizieren) müssen. Die Authentifizierung erfolgt typischerweise entweder durch Passwort oder mit public/private-Key (z.B. bei automatisierten Anmeldungen in Skripten wichtig) oder durch andere Authentifizierungsarten. Somit kann weder mitgelesen werden, noch kann sich jemand (unbemerkt) in die Mitte setzen (“Man-in-the-middle (MITM)-Attacke“) und beiden Partner die Gegenseite vorspielen.

Mit SSH lassen sich Dateien austauschen (mit sftp, scp) und Tunnel für unverschlüsselte Protokolle einrichten. Die Daten können auf Wunsch komprimiert übertragen werden und man kann Bildschirminhalte grafischer Programme (vom X-Server des Servers) übertragen.

Syntax: Ein minimaler Aufruf folgt dem Schema

ssh SERVER

dabei ist die Angabe des Benutzers (-l Benutzer) optional, wenn keiner angegeben wurde, wird der aktuelle Benutzername genommen.

ssh -l Benutzer SERVER

Bei langen Befehlszeilen lässt sich Zeit durch vorher festgelegte Optionen in Konfigurationsdateien oder über Aliase sparen.

Dateien austauschen:

sftp

eignet sich gut für einzelne und mehrere Dateien (Eingabe mget)

• Für das übertragen kompletter verzeichnis-struktionen taugt der Befehl sftp leider nichts, dafür nimmt man scp:

download:

scp benutzer@entfernterRechner:/Verzeichnis/Datei /lokalesVerzeichnis/Datei

upload:

scp /lokalesVerzeichnis/Datei benutzer@entfernterRechner:/Verzeichnis/Datei

Mit der Option -r lassen sich rekursiv ganze Verzeichnisse übertragen.

Eine sehr nützliche Eigenschaft von SSH ist die Möglichkeit (unverschlüsselte) Protokolle durch den verschlüsselten SSH-Tunnel zu schicken („tunneln“).

ssh user@remote.host -L 8080:127.0.0.1:80 -N -g

Dafür gibt man den lokalen Port an (hier 8080) und nach dem Doppelpunkt die Adresse an die es geleitet werden soll (hier wird „127.0.0.1:80“ als Ziel angegeben, d.h. der localhost (127.0.0.1) auf dem Port 80, also der entfernte Rechner selbst). Der Parameter “-g“ besagt das der Port auf allen Netzwerkschnittstellen geöffnet werden soll, “-N“ verbietet die Ausführung von Befehlen auf dem Zielrechner, was nur beim reinen tunneln sinnvoll ist.

Es gibt auch die Möglichekeit mit OpenSSH 4.3 eine Art VPN einzurichten: SSH_VPN.

Programmfenster grafischer (X-)Programme können auch über SSH übertragen werden. Dazu ruft man ssh zusätzlich mit der Option -X auf.

Also normalerweise

ssh -X SERVER

oder mit slogin:

slogin -X SERVER

Die Variable wird dann auf dem Host gleich korrekt gesetzt. In der SSH-Konfiguration muss X11Forwarding aktiviert sein (standard).

X11Forwarding yes
X11DisplayOffset 10

X11DisplayOffset sorgt für ausreichenden Abstand zu bereits existierenden Displays.

• Make SSH connections with PHP
• OpenSSH Teil 1: Grundlagen ( Teil 2: SSH-Tunnels; Teil 3: Firewalls durchbohren
• autossh: vermeidet „hängende“ Tunnel durch Testschleife und neuverbinden bei Abbruch.
• HOWTO: set up ssh keys
• SSH und SCP unter Unix
• Hilfe zu pscp
• OpenSSH
• weitere SSH-Erklärung
• sshd über das terminal neu starten
• Ssh warum?
• automatisierte SSH-Logins

• Mitigating the Security Risks of SSH

• OpenSSH-Client
• Kssh: KDE-Frontend
• lsh-client
• putty für X
• secpanel

• OpenSSH-Server: Der Standard-Server
• lsh-server
• dropbear: Ressourcenschonend, z. B. für embedded-Systeme

• Using SSH to access programs from an Ubuntu box

• Putty / KiTTY
• WinSCP

• Cygwin bzw. der Cygwin live-CD
• freesshd: kostenloser ssh-Server
• tectia-SSH-Server + Client (kommerziell)

Zum besseren Verständnis vorher die Authentifizierung des Servers:

Oft bekommt man beim (ersten) verbinden auf einen Server folgende Meldung:

user@hostname:~$ ssh -l root host.de
The authenticity of host 'host.de (123.123.123.123)' can't be established.
RSA key fingerprint is 06:1f:f0:9e:76:b1:4e:9e:8f:5f:29:11:56:71:5e:9e.
Are you sure you want to continue connecting (yes/no)?

Das bedeutet, dass er den Host bisher (unter dieser IP) nicht kennt und nicht gewähleistet werden kann, das dies auch wirklich der Server ist, zu dem man wollte. Daher sollte man nur in (gut) geschützten Netzwerken „yes“ eingeben, es sei denn man kann den Fingerabdruck („RSA key fingerprint“) eindeutig als den richtigen erkennen (durch Vergleich mit dem vorher notierten).

Wenn man „yes“ eingibt kommt folgende Meldung:

Warning: Permanently added 'host.de,123.123.123.123' (RSA) to the list of known hosts.

D.h. er fragt in Zukunft nicht mehr, da er in einer Liste von bekannten Server (in der Datei ~/.ssh/known_hosts) gespeichert hat. In Zukunft wird nur noch nach dem Passwort gefragt.

Bei Änderungen des Schlüssels auf dem Server (oder schlimmer: wenn ein Angreifer so tut als ob er der Server ist) wird der Verbindungsaufbau verweigert:

$ ssh SERVER
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for SERVER has changed,
and the key for the according IP address SERVER-IP
is unknown. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
01:12:34:56:78:90:12:12:34:56:78:90:12:34:56:78.
Please contact your system administrator.
Add correct host key in /home/USER/.ssh/known_hosts to get rid of this message.
Offending key in /home/USER/.ssh/known_hosts:4
RSA host key for SERVER has changed and you have requested strict checking.
Host key verification failed.

Wenn man sicher ist, dass die Änderung rechtens ist (z.B. weil man sie selber veranlasst hat ), löscht man aus seiner .ssh/known_hosts die angegebene Zeile (hier im Beispiel die 4. Zeile) heraus. Am einfachsten geht dies mit Editor der Wahl, die meisten unterstützen eine Option +ZEILENNR. Mit vim würde der Aufruf also

vim +4 ~/.ssh/known_hosts

lauten.

Die verantwortliche Option StrictHostKeyChecking steht im Standardfall auf ask (Benutzer bei unbekannten Schlüsseln fragen, bei geänderten Schlüsseln abbrechen) kann jedoch auch auf yes (keine neuen Schlüssel werden in die known_hosts hinzugefügt) oder no (alle neuen Schlüssel hinzufügen) gesetzt werden.

Es ist das Standardverhalten.

Der Server authentifiziert sich über seinen „Fingerabdruck“ der Client mit seinem (gültigen) Passwort.

Was aber wenn ich nicht ständig mein Passwort (wenn auch verschlüsselt) durch das Netz schicken will?

Das Konzept in Kurzform: Der Benutzer erzeugt ein Schlüsselpaar (einen öffentlichen, einen privaten Schlüssel). Diese Schlüssel werden auf dem lokalen Rechner gespeichert.
Auf dem entfernten Rechner, bei dem man sich einloggen will, speichert man den öffentlichen Schlüssel. Möchte man sich nun auf dem entfernten Rechner anmelden, sendet der entfernte Rechner eine, mit dem öffentlichen Schlüssel verschlüsselte Zufallszahl, welche der lokale Rechner mit dem privaten Schlüssel (und evtl Passwortabfrage für diesen) entschlüsselt. Die entschlüsselte Zahl wird zurück an den entfernten Rechner gesendet, welcher nun (wenn die Zahlen übereinstimmen) den Benutzer „Authentifiziert“ hat. Dabei wurde weder der öffentliche noch der private Schlüssel über das Netz geschickt, lediglich eine Zufallszahl.

Der entfernte Rechner authentifiziert sich auch selbst: gleiches Prinzip - öffentlicher Schlüssel bei uns, privater Schlüssel auf entferntem Rechner.

Die Einstellung PubkeyAuthentication regelt ob Public-Key-Authentifizierung erlaubt ist (Standardwert ist yes).

Achtung: da kein Passwort abgefragt wird, muss man sicher gehen, dass keiner der privaten Schlüssel im fremde Hände fällt. Außerdem sollte eine Passphrase für den privaten Schlüssel vergebene werden.

Das Werkzeug ssh-copy-id nimmt alle Schritte (vom Client aus) automatisch vor.

1. man legt ggf. einen eigenen Benutzer an
2. man ruft ssh-keygen -d auf. Ausgabe:

   $ ssh-keygen -d
   Generating public/private dsa key pair.
   Enter file in which to save the key (/home/USER/.ssh/id_dsa): 
   Created directory '/home/USER/.ssh'.
   Enter passphrase (empty for no passphrase): 
   Enter same passphrase again: 
   Your identification has been saved in /home/USER/.ssh/id_dsa.
   Your public key has been saved in /home/USER/.ssh/id_dsa.pub.
   The key fingerprint is:
   01:23:45:67:89:01:23:45:67:89:01:23:45:67:89:01 USER@HOST
   

   id_dsa ist der private Schlüssel und id_dsa.pub ist der öffentliche Schlüssel.

3. nun kopieren wir den/die Schlüssel auf den Server: man ruft

   ssh-copy-id -i ~/.ssh/id_dsa.pub user@clientHOST

   Ohne Angabe von -i nimmt ssh-copy-id die Existenz von ~/.ssh/identity.pub an und versucht diesen öffentlichen Schlüssel zu übertragen.

• Auf dem Host
  1. man legt ggf. einen eigenen Benutzer an
  2. man ruft ssh-keygen -d auf. Ausgabe:

     $ ssh-keygen -d
     Generating public/private dsa key pair.
     Enter file in which to save the key (/home/USER/.ssh/id_dsa): 
     Created directory '/home/USER/.ssh'.
     Enter passphrase (empty for no passphrase): 
     Enter same passphrase again: 
     Your identification has been saved in /home/USER/.ssh/id_dsa.
     Your public key has been saved in /home/USER/.ssh/id_dsa.pub.
     The key fingerprint is:
     01:23:45:67:89:01:23:45:67:89:01:23:45:67:89:01 USER@HOST
     

     id_dsa ist der private Schlüssel und id_dsa.pub ist der öffentliche Schlüssel.

  3. man kopiert /home/USER/.ssh/id_dsa und /home/USER/.ssh/id_dsa.pub auf die Clients
• auf den Clients:
  1. den öffentlichen Schlüssel an die authorized_keys anhängen:

     cat id_dsa.pub >> ~/.ssh/authorized_keys

Das Verzeichnis ~/.ssh und die Datei ~/.ssh/authorized_keys darf nicht von der Gruppe des Benutzers beschrieben werden können. Sonst scheitert die Authentifizierung wenn der SSH-Dienst des Servers StrictModes konfiguriert hat.

Heise Netze beschreibt das in dem Artikel SSH absichern gut.

Die Authentifizierung erfolgt anhand des Hostnamens und dem Benutzer, i. d. R. ohne weitere Passwortabfrage.

incl. PAM

Die Authentifizierung wird durch ein Kerberos-Ticket wahlweise stattdessen oder zusätzlich durch andere Methoden wie Systempasswort. Ab Version 3.7 wird Kerberos v4 nicht mehr unterstützt.

Man kann die privaten Schlüssel auf Smartcards speichern. OpenSSH unterstützt Cyberflex-Smartcards sowie PKCS#15 unter OpenSC.

Bei OpenSSH werden Einstellungen

• für den (openssh-) Server: In der Datei /etc/ssh/sshd_config
• für (openssh-) Client: Systemweit in den Dateien /etc/ssh/ssh_config oder Benutzerspezifisch in ~/.ssh/config

vorgenommen.

Die folgenden Dateien werden von SSH (und darauf basierenden Programmen wie scp) benutzt.

Die privaten Schlüssel dürfen nur vom Benutzer lesbar sein, sonst werden diese ignoriert.

Anmerkung: ~ steht für das Homeverzeichnis.

Bei häufigen Verbindungsabbrüchen kann man

TCPKeepAlive no
ClientAliveInterval 150

setzen. Das standardmäßige “TCPKeepAlive yes“ verursacht Abbrüche auch bei kurzen Unterbrechungen (und kann sowieso von einem Angrifer gefälscht werden) während ClientAliveInterval innerhalb von 150 Sekunden eine kryptografisch kodierte Antwort von Client erwartet bevor die Verbindung abgebrochen wird.

Lange Parameterlisten kann man vermeiden indem man in Konfigurationsdateien Einstellungen hinterlegt. Diese werden Systemweit in den Dateien /etc/ssh/ssh_config oder Benutzerspezifisch in ~/.ssh/config vorgenommen.

Host *.domain.de
 Port 12345
 User ich
 ForwardAgent yes
 Compression yes
 ForwardX11 yes

Somit reicht der Aufruf von ssh subdomain.domain.de ohne die o.g. Einstellungen noch extra zu übergeben.

Auch Hostname+Domain kann man schon vorgeben, somit verkürzt sich die Kommandozeile auf ssh RECHNER:

host RECHNER
 Hostname die.richtige.URL.de

Alternativ zur Konfiguration der einzelnen Hosts kann man spezialisierte Tools benutzen. Dann wird der Aufruf über „TOOLNAME Hostalias“ erfolgen, also etwa

sshmgr Rechner1

• sshm
• connmgr (sshmgr): Funktioniert auch mit Vervollständigung auf der Bash-Shell; Perl-basiert

Als Minimum würde ich die folgenden Einstellungen in der Datei /etc/ssh/sshd_config vornehmen:

1. nur Protokollversion 2 benutzen

   Protocol 2

2. keine root-logins zulassen

   PermitRootLogin no

   Administration wird ausschließlich über normale Benutzer vorgenommen und dann fallweise per sudo oder bei Bedarf permanent (su) auf root-Rechte wechseln. Dazu muss ein Eintrag in der Datei /etc/sudoers angelegt werden (mit dem Befehl visudo):

   Benutzer1  ALL=(ALL) ALL

   Es kann auch die Berechtigung für einzelne Aufgaben vergeben werden (zur Not auch ohne Passworteingabe)

3. nur bestimmten Benutzern den Login erlauben:

   AllowUsers Benutzer1 Benutzer2

4. nur bestimmten Gruppen den Login erlauben:

   AllowGroups Gruppe1 Gruppe2

5. maximale Anzahl der Loginversuche begrenzen: Nur 3 Versuche (pro Verbindung) zulassen

   MaxAuthTries 3

Wer ganz sicher gehen will, sperrt SSH in einen Käfig (chroot von change root). Damit kann der eingesperrte Benutzer nur innerhalb seiner Ordner navigieren. Allerdings bietet bisher keine Distribution diese Funktionen von Haus aus an, also muss man selber eine gepatchte Version kompilieren und installieren.

• chrootssh.sourceforge.net
• chroot sshd/sftp
• Chrooted SSH HowTo
• Chrooted SSH/SFTP Tutorial (Debian Etch)
• Build a chrooted sftp Environment

Durch port knocking (Senden eines speziellen Pakets, erst dann wird der Port freigeschaltet) ist man vor unbekannten Sicherheitslücken (0-Day Exploits) in SSH und vor Portscans geschützt.

• fwknop ("FireWall KNock OPerator")
• Single Packet Authorization (Port-knocking)

Wenn man SSH auf den Standard-Port betreibt, sieht man in den Log-Dateien eine Vielzahl von (fehlgeschlagenen) Login-Versuchen. Meist werden Standardbenutzer wie root und Standardpasswörter probiert.

Zur Abwehr kann man Log-Based Intrusion Detection systems (LIDS) (wie denyhosts oder fail2ban) benutzen, die z.B. ab einer einstellbaren Anzahl von Fehlversuchen den angreifenden Rechner (temporär) sperren.

Sauberer ist meist eine spezielle Firewallregel. Damit spart man sich die möglichen Sicherheitslücken durch das parsen der Log-Dateien die die Tools zwangsläufig durchführen müssen. Der Programmcode der im Bereich des Kernels angesiedelten Firewalls ist besser auf Sicherheitslücken überprüft.

• Block brute force attacks with iptables
• Firewalling with OpenBSD's PF packet filter

Evtl. ist es sinnvoll auf einen hohen Port wechseln (wenn das für die Benutzer ok ist, hier im Beispiel auf 54321):

Port 54321

• Defending against SSH Brute force attacks
• sshguard: Protection for OpenSSH

OpenSSH ab Version 4.0 enthält ein neues Feature: ControlMaster. Damit geht der Verbindungsaufbau bei mehrfachen Verbindungen deutlich schneller weil die aktuell existierende Verbindung erneut benutzt wird.

• Accelerating (initiating) OpenSSH connections with ControlMaster

Mit sshfs steht unter Linux ein Userspace-Dateisystem basierend auf FUSE zur Verfügung. Damit kann man ganze Verzeichnisbäume in das lokale Dateisystem am sog. Mountpoint einhängen. Ab Kernelversion 2.6.14 gehört FUSE standardmäßig zum Kernel.

Mount a remote file system through ssh Using sshfs

sshfs ssh-konto@ssh-server:[PFAD] mount-point

Für den Befehl muss unter Ubuntu das Paket sshfs mit

apt-get install sshfs

installiet und evtl. mit

sudo modprobe fuse

das Kernelmodul für FUSE geladen werden.

Nützlich können sich die Optionen (Parameter -o) und dann die folgenden Schlüsselwörter:

• reconnect für das erneute Verbinden,
• uid=Zahl und guid=Zahl sowie diverse caching Einstellungen auswirken (siehe Befehl man sshfs).

fusermount -u mount-point

Wenn man nicht eine zweite SSH-Verbindung aufbauen will (gerade bei Sprüngen über mehrere Systeme kann das nervig sein), braucht man zssh. Das ist ein Programm, das sich um ssh „herumlegt“ (ein sog. „wrapper“) und Datenaustausch mittels zmodem-Protokoll bietet.

Man muss es nur auf der lokalen Computer installieren (apt-get install zssh bei Debian/Ubuntu) und auf dem entfernten Rechner „lrzsz“.

Eventuell erzeugt man sich einen Alias in der ~/.bashrc, neue Zeile mit:

alias ssh=zssh

damit wird bei der Eingabe von ssh automatisch mit zssh ersetzt. Dies ist für die Bash-Shell angegeben, aber nicht unbedingt nötig.

Auf dem verbundenen Rechner/Server muss man dann nur noch mit STRG-Leertaste in den interaktiven Modus gehen.

Um eine Datei zu senden gibt man

sz -e <Datei>

ein. Der Parameter “-e“ vermeidet Fehler bei fehlerhaften 8-Bit-Terminals.

SSH ist als sichere Variante zu ftp(s) beim Upload von Dateien nützlich. Dennoch muss man dafür dem Benutzer auch einen Login geben der es dem Benutzer emöglicht Programme und andere Tätigkeiten auszuführen die evtl. sicherheitskritisch sind. Spezielle Shells (technisch meist genauer „wrapper“) beschränken die Funktionalität von SSH.

• chainssh: Kürzt mehrere Logins hintereinander ab
• scponly: Erlaubt nur Lese- und Schreibzugriff auf lokale Dateien
• rssh: Erlaubt nur scp und/oder sftp, chroot ist auch möglich. Es wird aber auch rdist, rsync und cvs unterstützt.