Wer bis hierhin durchgehalten hat, verdient sich ein Lob, hat aber nur an der Oberfläche geschnuppert. Jetzt endlich geht es ans Eingemachte.
SSH wird von vielen als sicher betrachtet, was wahrscheinlich an dem Wörtchen „Secure“ in „Secure Shell“ liegt. „Secure“ bezieht sich aber nur darauf das alle Inhalte einer SSH Verbindung stark verschlüsselt sind, also nicht abgehört werden können.
In Wirklichkeit ist SSH das Schweizer Taschenmesser zum Aushebeln von Sicherheitseinstellungen. Wie man dies nutzt und wie man sich dagegen schützt wird hier beschrieben.

Was ist eigentlich unter einem SSH-Tunnel zu verstehen? Eine etablierte SSH-Verbindung kann genutzt werden um verschiedenste Daten sozusagen Huckpack mit zu transportieren. Wenn man sich eine SSH Verbindung als Kabel zwischen zwei Endpunkten vorstellt und sich das Kabel in einzelne Adern aufteilt, ist die SSH-Verbindung die Isolierung und die Tunnel sind die einzelnen Fasern die davon eingeschlossen sind. Unter dem Schutz der Isolierung (die verschlüsselte SSH Verbindung) können also viele Adern (die Tunnel) zu anderen Zwecken gebraucht werden.
Betrachten wir den hilfreichen Einsatz eines Tunnels an einem Beispiel an. Ich arbeite von zu Hause und nutze einen SSH-Zugang um ins Firmennetz zu gelangen. Ich habe zwar eine Verbindung und kann auf einzelnen Servern Befehle absetzen, aber Zugriff auf das Intranet der Firma habe ich nicht. Hätte ich aber gerne und fange erstmal mit einem einfach Tunnel an. Webserver lauschen i.d.R. auf Port 80 oder 443, je nachdem ob http oder https verwendet wird. Was ich also brauche um eine interne Webseite des Servers webserver.firma.de im Browser anzusehen ist eine Verbindung auf den Ports 80 und/oder 443. Leider habe ich nur den Zugang über Port 22 (SSH).
Ein kleiner SSH Tunnel schafft hier Abhilfe:

ssh -L 8080:webserver.firma.de:80 -L 8443:webserver.firma.de:443 user@sshserver.firma.de

Das war das ganze Geheimnis. Betrachten wir mal, was geschieht. Die Option „-L 8080:webserver.firma.de:80“ öffnet auf meinem PC den Port 8080 und leitet den dort eintreffenden Traffic über die SSH Verbindung an „sshserver.firma.de“ weiter. Dieser wiederum nimmt die Daten, mit denen SSH eigentlich nicht anfangen kann, und leitet sie freundlich an den Port 80 von „webserver.firma.de“ weiter. Gebe ich im Browser nun „http://localhost:8080“ ein, gelange ich unversehens auf die gewünschte Seite. Das gleiche gilt analog mit den Ports 8443 und 443 bei Benutzung von https.
Geht das auch andersherum? Kann ich, obwohl der firmeneigene Proxy und die Firewall es verbieten Kontakt mit GoogleMail aufnehmen? SSH und die Tunnel sind auch hier die Lösung.

ssh -R 8443:mail.google.com:443 user@sshserver.firma.de

Problem gelöst. Auf dem Server „sshserver.firma.de“ wird der Port 8443 geöffnet und mein SSH Client ist so freundlich dort eingehenden Traffic an „mail.google.com“ weiterzuleiten. Der Ausbruch aus dem ach so sicheren Firmennetz ist gelungen.
Das erscheint nicht praktikabel, wenn ich von zu Hause auf mehrere Webserver der Firma zugreifen will. Aber die Entwickler von SSH haben an alles gedacht. Der Schlüssel zur Firma heisst „Socks Proxy“ oder „Dynamic Forwarding“. Jedes Programm, das die Nutzung eines Proxy Servers unterstützt kann davon profitieren.

ssh -D 3128 user@sshserver.firma.de

startet einen Socks Proxy auf meinem PC, der auf Port 3128 lauscht. Dort eingehender Traffic wird über die SSH Verbindung zu „sshserver.firma.de“ geschaufelt und von dem dortigen Gegenstück wie erwünscht (also dynamisch) verteilt. Wenn ich in meinem Web Browser jetzt den Socks5 Proxy einschalte und auf „localhost“ Port 3128 lege, komme ich an alle Webserver der Firma, zu denen „sshserver.firma.de“ Netzwerkzugang hat. Nette Geschichte und hilfreich für's Home Office. Ob es allerdings gewünscht ist ziehe ich mal in Zweifel.
Wenn der „Einbruch“ so einfach ist, wie sieht es mit dem „Ausbruch“ aus? Um von der Firma das gesamte Internet (Browser, Mail etc.) zu erreichen, obwohl Firewalls und Proxies mich zu stoppen versuchen, braucht es nur SSH. Da aber davon auszugehen ist, das die Firma neben der Browser Ports auch den SSH Port sperrt muss ich ein wenig tricksen. Ich benötige zwei Dinge,

1. einen SSH Server, der uneingeschränkten Zugang zum Internet hat
2. einen SSH Zugang aus der Firma zu diesem Server

Der SSH Server ist das geringste Problem, ich starte einfach den Dienst auf meinem heimischen PC. Den Zugang aus der Firma zu diesem SSH Server ist mit einem Tunnel einfach herzustellen

ssh -R 2222:localhost:22 user@sshserver.firma.de

und nun auf dem „sshserver.firma.de“ den Befehl

ssh -D 3292 -p 2222 heimuser@localhost

Ein wenig aufwendiger, aber mit zwei Befehlen durchaus im Rahmen des Machbaren.

Selbstverständlich kann man auch einen bestehenden Tunnel nutzen um darin einen weiteren Tunnel anzulegen. Die mehrfache Schachtelung macht es fast unmöglich eine solch Verbindung zu entschlüsseln, da man ja nicht weiß wie viele Ebenen existieren. Darüberhinaus kann ein existierender Tunnel genutzt werden, um ein VPN in diesem Tunnel zu verbergen. Damit wird die Möglichkeit geschaffen ein sicheres Netz mit dem Heimnetz oder auch mit dem Internet zu verbinden.

Stellt man sich nun einmal auf die andere Seite, also nicht die des SSH Clients sondern auf die des SSH Server Administrators, muss man sich ernsthaft fragen, ob SSH Verbindungen überhaupt zugelassen werden können. Die Antwort ist, wie immer bei der Konfiguration hochflexibler Lösungen, ein klares Ja, aber.
SSH bietet nicht nur die clientseitigen Möglichkeiten, sondern auch die Einschränkung auf der Server Seite. Im Folgenden wenden wir uns einzelnen Konfigurationseinstellungen zu.

Für die Anmeldung an einem SSH-Server stehen unterschiedliche Möglichkeiten zur Verfügung:

• Password
• SSH Keys
• PAM (einschließlich LDAP oder OATH (One Time Authorization Token) )
• Kerberos
• u.v.a.

Der Konfigurationsparameter „AuthenticationMethods“ steuert, welche Art zuässig, bzw. gefordert wird. Eine einfache Zweifaktor Authentifizierung kann implementiert werden, indem man den Wert „publickey,password publickey,keyboard-interactive“ vergibt. Der Server verlangt nun sowohl einen Public Key als auch ein Passwort. Nur in Kombination ist eine Anmeldung zulässig.
Die Verwendung von Puclic Keys kann geregelt werden, indem man es dem Administrator statt jedem User überlässt, die authorized_keys Datei zu pflegen. Normalerweider liegt diese Datei in dem Verzeichnis ~/.ssh/ . Verlegt man dies durch die Angabe z.B von

AuthorizedKeysFile /etc/ssh/.ssh/%u/ 

an einen Ort an dem der User keinen Schreibzugriff hat, kann nur noch der Administrator Public Keys dort eintragen. Im Zusammenspiel mit signierten Public Keys (siehe TrustedUserCAKeys) kann man den Einsatz nicht signierter Public Keys unterbinden.
Es gibt also auf der Ebene Authentifizierung eine Reihe von Möglichkeiten nur vertrauenswürdigen Benutzern Zugriff zu gewähren.

Der Einsatz von Tunneln sollte reglementiert werden. Zwei Paramter erlauben ein solche Einschränkung:

AllowTcpForwarding no
PermitOpen none

Ist der Einsatz eines Tunnels gewünscht, oder unerlässlich, kann dieser in einem Match Block gezielt erlaubt werden

Match Group tunnel
  AllowTcpForwarding yes
  PermitOpen dbserver:1521

Auch die Beschränkung zum Öffnen eines Ports auf bestimmte, geprüfte und somit als sicher geltende Scripts kann helfen. Der entsprechende Paramter ist „ForceCommand“ und kann auch innerhalb eines Match Blocks benutzt werden. Zwingende Commands und andere Einschränkungen können auch in der Signatur eines Public Keys untergebracht werden (alternativ, bei nicht signierten Keys, geschieht die in der authorized_keys Datei).

Die Angabe von „PermitTunnel no“ in der sshd_config verhindert den Aufbau von VPNs, die in einer SSH Session verborgen werden. Dieser Parameter kann ebenfalls in einem Match Block angewendet werden.

Ist es einem Client erlaubt einen Port zu öffnen, muss man sich entscheiden ob der Port nur von dem Rechner benutzt werden kann, auf dem er geöffnet wurde, oder ob er auch von anderen Rechner angesprochen werden darf. Der Parameter „GatewayPorts“ steuert dies und der Default von „No“ sollte nur geändert werden, wenn man das, was in der man page dazu steht vollständig verstanden hat.

Muss man Fremden Zugang gewähren muss man deren Möglichkeiten soweit wie möglich einschränken. Die Einrichtung einer CHROOT Umgebung sperrt solche Benutzer ein einen „Käfig“ und potentieller Schaden beschränkt sich auf den Inhalt der CHROOT Umgebung. Anleitung zur Erstellung einer CHROOT Umgebung sind im Internet leicht zu finden. ChrootDirectory /pfad/zur/chroot