SSH: Unterschied zwischen den Versionen
Dirk (Diskussion | Beiträge) |
|||
(39 dazwischenliegende Versionen von 18 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{Artikelstil}}{{Veraltet}} | |||
{{righttoc}} | |||
SSH | Secure Shell oder SSH ist ein Netzwerkprotokoll, welches den sicheren Datenaustausch zwischen zwei Computern über ein Netzwerk gestattet. SSH bietet dank Verschlüsselung Diskretion und Integrität der versendeten Daten. Als Verschlüsselungsverfahren wird ein asymmetrisches Kryptosystem (Verschlüsselung durch Public- und Private-Keys) eingesetzt, um den zugreifenden Computer und - falls benötigt - auch den zugreifenden Benutzer zu verifizieren. | ||
SSH wird normalerweise benutzt, um sich in einem entfernten System einzuloggen und Kommandos auszuführen. Zusätzlich werden Tunneling, das Transmission Control Protocol (TCP) und [[X|X11]] Verbindungen unterstützt. Datentransfer kann durch die Protokolle SFTP und SCP erreicht werden. | |||
( | Standardmäßig lauscht der SSH-Server auf den Standard-TCP-Port 22. Ein SSH-Client-Programm wird normalerweise zur Herstellung einer Verbindung zu einem ''sshd'' (Secure Shell Daemon) benutzt. Beide Programme sind für die meisten modernen Betriebssysteme vorhanden. U.a. für Mac OS X, GNU/Linux, Solaris und OpenVMS. Proprietäre, freie und Open Source Versionen in unterschiedlicher Komplexität und Vollständigkeit existieren. | ||
(Quelle: [http://en.wikipedia.org/wiki/Secure_Shell Secure Shell]]) | |||
= OpenSSH = | = OpenSSH = | ||
OpenSSH (OpenBSD Secure Shell) ist eine Sammlung von Programmen, die eine verschlüsselte Verbindung über ein Computernetzwerk mit dem SSH Protokoll erlauben. Sie wurde als eine Open-Source-Alternative zu der proprietären Secure Shell Software Suite des Unternehmens SSH Communications Security erstellt. OpenSSH wird als Teil des OpenBSD Projektes entwickelt und von Theo de Raadt geleitet. | OpenSSH (OpenBSD Secure Shell) ist eine Sammlung von Programmen, die eine verschlüsselte Verbindung über ein Computernetzwerk mit dem SSH-Protokoll erlauben. Sie wurde als eine Open-Source-Alternative zu der proprietären Secure Shell Software Suite des Unternehmens SSH Communications Security erstellt. OpenSSH wird als Teil des OpenBSD Projektes entwickelt und von Theo de Raadt geleitet. | ||
OpenSSH wird gelegentlich mit dem ähnlich benannten OpenSSL verwechselt. Beide Projekte haben allerdings verschiedene Zwecke und werden von verschiedenen Teams entwickelt. Der ähnliche Name kommt allein von ähnlichen Zielen. | OpenSSH wird gelegentlich mit dem ähnlich benannten OpenSSL verwechselt. Beide Projekte haben allerdings verschiedene Zwecke und werden von verschiedenen Teams entwickelt. Der ähnliche Name kommt allein von ähnlichen Zielen. | ||
{{installation|repo=core|paket=openssh}} | |||
Nach der Installation stehen einige Programme zur Verfügung: | |||
* {{ic|ssh}} Ein Programm, mit dem man verschlüsselt auf die Shell entfernter Rechner zugreifen kann, aber auch Verbindungen tunneln kann. | |||
* {{ic|scp}} Ein Programm, um verschlüsselt Dateien zu übertragen. Es funktioniert ähnlich wie {{ic|cp}} kann jedoch auf Dateien entfernter Rechner zugreifen. | |||
* {{ic|ssh-keygen}} Mit diesem Programm kann man Schlüssel erstellen, welche die Passwort Authentifizierung auf entfernten Rechnern ersetzen können. | |||
* {{ic|ssh-copy-id}} Mit diesem Programm können die erstellten Schlüssel für die Authentifizierung einfach und sicher ausgetauscht werden. | |||
* {{ic|sshd}} Ein Daemon, der verwendet werden kann, um den Computer als entfernten Computer verwenden zu können. | |||
== | == Verwendung == | ||
===Client=== | ===Client ssh=== | ||
Die SSH Client Konfigurationsdatei wird unter | Die SSH-Client-Konfigurationsdatei wird unter {{ic|/etc/ssh/ssh_config}} automatisch angelegt. | ||
Die Standardkonfiguration ist für viele Fälle absolut ausreichend. Um die Sicherheit ein wenig zu erhöhen, | |||
kann die '''ProtocolVersion''' auf 2 beschränkt werden. Die Standardeinstellung 2,1 besagt, dass zuerst eine Verbindung | |||
über Version 2 versucht werden soll. Version 1 öffnet einem aktiven Angreifer einige Sicherheitsrelevanten Möglichkeiten wie MITM oder | |||
Datainsertion [https://www.centos.org/docs/4/html/rhel-rg-en-4/s1-ssh-version.html [1]][http://cs.ucsb.edu/~koc/ns/projects/02Reports/YW.pdf [2]]. | |||
Mit {{ic|$ ssh [-p port] [user@]host}} wird eine sichere Verbindung zum Server '''host''' aufgebaut. Die Angabe von Port und User sind dabei optional. Wird der User weggelassen, so nimmt '''ssh''' den aktuellen Benutzernamen für den Verbindungsaufbau. | |||
Beispiele | |||
* {{ic|# ssh root@archlinux.com}} Baut eine root Verbindung zum Server archlinux.com auf. | |||
* {{ic|# ssh -p 2222 max@192.168.0.2}} Baut eine Verbindung zum Computer 192.168.0.2 auf Port 2222 auf und versucht sich dort mit dem Benutzernamen max einzuloggen. | |||
* {{ic|# ssh ::1}} Baut eine Verbindung zu localhost über IPv6 auf. | |||
===Daemon sshd.service=== | |||
Die Konfigurationsdatei des Daemons {{ic|/etc/ssh/sshd_config}} sollte vor dem Start entsprechend angepasst werden: | |||
* {{ic|AllowUsers user1 user2}} schränkt den Zugriff auf die Benutzer user1 und user2 ein. | |||
* {{ic|AllowGroups sshusers}} schränkt den Zugriff auf Benutzer der Gruppe sshusers ein. | |||
* {{ic|Protocol 2}} beschränkt den Server lediglich auf die Verwendung von Protocol Version 2. | |||
* {{ic|LoginGraceTime 120}} bedeutet, dass man nach 120 inaktiven Sekunden automatisch getrennt wird. | |||
* {{ic|PermitRootLogin no}} verbietet einen direkten Login des Benutzers root. Aufrufe per {{ic|sudo}} bleiben davon unberührt. | |||
* {{ic|PasswordAuthentication no}} Kann benutzt werden, wenn man anstatt Passwörtern nur noch Schlüssel für die Authentifizierung ermöglichen will. | |||
* {{ic|ChallengeResponseAuthentication no}} ChallengeResponseAuthentication kann sicher implementiert sein. Ist jedoch das Backend falsch konfiguriert, wird hier ebenfalls nur nach dem Passwort gefragt. Es bietet sich daher an, sofern man sich mit PAM aber nur eine Authentifizierung über Schlüssel zulassen möchte zu deaktivieren. | |||
* {{ic|ListenAddress ::}} Um auch IPv6 Verbindungen zuzulassen. | |||
In der Datei {{ic|/etc/issue}} kann eine Nachricht hinterlassen werden, die bei jedem Login über ssh angezeigt wird. | |||
Der Daemon welcher die Verbindung zu dem Computer zulässt sollte nur gestartet werden, wenn man auf den Computer entfernt zugreifen möchte. | |||
Der Name des Services ist {{ic|sshd.service}} und kann wie üblich über {{ic|# systemctl}} konfiguriert werden. | |||
# systemctl enable sshd.service | |||
# systemctl {start|stop|restart} sshd.service | |||
=== Schlüsselgenerierung ssh-keygen und ssh-id-copy === | |||
#ssh-keygen -t rsa | |||
Erzeugt einen privaten und einen öffentlichen Schlüssel. Normal werden diese in {{ic|/home/user/.ssh/id_rsa}} und {{ic|/home/user/.ssh/id_rsa.pub}} abgelegt. Der private Schlüssel {{ic|id_rsa}} sollte niemals in fremde Hände geraten, da er für die Authentifizierung auf allen konfigurierten Systemen ermöglicht! Der öffentliche Schlüssel kann auf einen SSH-Server mit folgendem Befehl installiert werden um sich anschließend ohne Passwort einzuloggen: | |||
. | # ssh-copy-id -i /home/user/.ssh/id_rsa.pub user@host | ||
. | Weitere Infos findet man in dem Artikel [[SSH-Authentifizierung mit Schlüsselpaaren]]. | ||
=== Dateiübertragung scp === | |||
. | Der Befehl {{ic|scp}} funktioniert im wesentlichen genau wie {{ic|cp}} jedoch können Ziel und Quelldateien auf verschiedenen über SSH zugänglichen Computern liegen. Am besten versteht man {{ic|scp}} an einigen Beispielen: | ||
. | * {{ic|scp mypicture.png max@mustermannserver.net:/home/max/mypicture.png}} Überträgt die Datei mypicture.png auf den mustermannserver in /home/max/. Dabei wird der Benutzer max zur Authentifizierung am Zielserver verwendet. | ||
* {{ic|scp max@mustermannserver.net:/home/max/mypicture.png ./mypicture.png}} Kopiert die Datei vom mustermannserver zum lokalen Computer | |||
* {{ic|scp root@server1:/etc/fstab root@server2:/etc/fstab}} überträgt die fstab Datei von Server1 nach Server2. | |||
. | Natürlich können auch ganze Verzeichnisse kopiert werden oder rekursive Befehle genutzt werden. Dabei geht man exakt so vor wie bei cp. | ||
= Tipps und Tricks = | |||
== Verschlüsselter Socks4 Proxy == | |||
Ein Rechner, auf dem ein SSH-Daemon läuft zu dem man einen Zugang hat, kann verschlüsselt als Proxy verwendet werden. Das bedeutet man kann alle Verbindungen verschlüsselt über diesen Computer weiterleiten. Dies kann für mehrere Szenarien verwendet werden: | |||
* Gateway Zugang zu einem Firmennetz | |||
* Sicherer Internetzugang in einem unverschlüsselten oder unsicheren WLAN | |||
* Anonymisierung im Internet | |||
* Sichere Verbindung zweier entfernter Firmenstandorte | |||
{{achtung|Die Verbindung wird nicht bis zum Zielrechner verschlüsselt, sondern nur bis zum SSH Server!}} | |||
$ ssh -ND localhost:8080 user@host | |||
Dazu | Dieser Befehl öffnet auf dem Lokalen Computer den Port 8080 als Socks4 Proxyverbindungen. Dazu wird der Computer '''host''' als Proxy verwendet. | ||
Die Einschränkung '''localhost''' besagt dabei, dass nur der lokale Computer eine Verbindung zum Port 8080 aufbauen darf. Man kann hier auch einen IP Bereich angeben und so anderen Computern im lokalen Netzwerk ermöglichen den Tunnel zu benutzen. Die Verbindung wird für '''user''' authentifiziert und danach der lokale Proxyport freigegeben. Die Wahl des Ports 8080 kann beliebig erfolgen. Alle Programme die den Tunnel nutzen sollen, müssen auf diesen Port konfiguriert werden. Der Parameter N besagt lediglich, dass keine Eingabeaufforderung aktiv werden soll und D ist für das öffnen des Ports verantwortlich. | |||
Um den Aufwand zu reduzieren kann man einen alias in ~/.bashrc hinzuzufügen: | |||
= | alias sshtunnel="ssh -ND localhost:8080 -v user@host" | ||
Das '''v'''-Flag (für verbose - gesprächig) wird hinzugefügt, damit man an den Ausgaben erkennen kann ob die Verbindung aufgebaut wurde. | |||
{{achtung|Nur Programme bei denen ein Socks4 Proxy auf localhost:8080 konfiguriert wurde benutzen diesen verschlüsselten Tunnel. Alle anderen Programme schicken ihre Pakete nach wie vor direkt auf den Weg!}} | |||
== X11 weiterreichen == | |||
Um grafische Programme durch eine SSH-Verbindung zu benutzen, muss man das Weiterreichen von X11 aktivieren. Damit können Programme entfernt ausgeführt jedoch die graphische Oberfläche lokal angezeigt werden. Man installiert dazu das Paket {{ic|xorg-xauth}} auf dem Server und ändert folgende Einstellungen | |||
* Aktiviere die '''AllowTcpForwarding''' Option in der '''sshd_config''' auf deinem '''Server'''. | |||
* Aktiviere die '''X11Forwarding''' Option in der '''sshd_config''' auf deinem '''Server'''. | |||
* Ändere die '''X11DisplayOffset''' Option in der '''sshd_config''' auf deinem '''Server''' auf 10. | |||
* Aktiviere die '''X11UseLocalhost''' Option in der '''sshd_config''' auf deinem '''Server'''. | |||
* Aktiviere die '''ForwardX11''' Option in der '''ssh_config''' auf deinem '''Client'''. | |||
Um die Verbindung zum X11 aufzubauen fügt man X oder Y (für sicheres Verbinden) beim Verbindungsaufbau hinzu: | |||
# ssh -X[Y] -p port user@host | |||
Startet man nun ein grafisches Programm wie {{ic|xclock}} in der Eingabeaufforderung so wird die Anwendung auf '''host''' gestartet, die GUI erscheint jedoch lokal. | |||
== Port Weiterleitung mit SSH == | |||
SSH erlaubt es auch einzelne Ports verschlüsselt zu verknüpfen. Dazu können alle Verbindungen auf einem Quellport zu einem Zielport über einen konkreten Rechner weitergeleitet werden. | |||
ssh -g -L 120:ZIEL:80 user@host | |||
Dieser Befehl öffnet einen lokalen Port (120) und leitet alle Verbindungen auf diesem Port über '''host''' zum Port 80 auf '''Ziel''' weiter. | |||
ssh -g -L8080:192.168.0.23:80 user@sshgateway.firma.net | |||
* 192.168.23 ist dabei z.B. ein Webserver der auf Port 80 im lokalen Netzwerk von firma.net hört. | |||
* Öffnet man nun http://localhost:8080, so werden die Daten an den sshgateway.firma.net weitergeleitet, welche die Zustellung an 192.168.23 übernimmt. | |||
{{achtung|Falsch konfigurierte SSH-Gateways können ganze Firmennetze kompromittieren!}} | |||
Man kann den Parameter -L mehrmals verwenden: | |||
ssh -g -L8080:192.168.0.23:80 -L8081:192.168.0.24:80 user@sshgateway.firma.net | |||
Nutzen man statt dem Schalter "-L" den Schalter "-R", so wird aus der Lokalen Weiterleitung eine Remote Weiterleitung. Man kann damit dem Zielrechner die Verwendung eines lokalen Services ermöglichen. | |||
== Ein entferntes Filesystem mit SSHFS mounten == | |||
Zuerst muss SSHFS installiert und das fuse-Modul geladen werden. Wie man das fuse Modul automatisch lädt kann dem Artikel [[Kernelmodule]] entnommen werden. | |||
# pacman -S sshfs | |||
# modprobe fuse | |||
Um nun einen entfernten Ordner zu mounten, erstellt man einen Ordner und verlinkt diesen über '''sshfs''': | |||
# mkdir ~/remote_folder | |||
# sshfs USER@remote_server:/path/to/folder ~/remote_folder | |||
Das Kommando oben wird den Ordner '''/tmp''' auf dem Server in den Ordner '''~/remote_folder''' auf deinem lokalen Computer einhängen. Schreibvorgänge in diesem Ordner werden per SFTP ausgeführt. Mit {{ic|#fusermount -u ~/remote_folder}} kann das entfernte Verzeichnis wieder ausgehängt werden. | |||
Möchte man einen Eintrag in die [[fstab]] machen um das Verzeichnis automatisch beim Systemstart einzuhängen, fügt man folgende Zeile in {{ic|/etc/fstab}} ein: | |||
sshfs USER@remote_server:/path/to/source /path/to/target fuse defaults,auto,allow_other 0 0 | |||
Dabei gibt {{ic|/path/to/source}} das Verzeichnis auf dem Server und {{ic|/path/to/target}} das lokale Verzeichnis an. Man sollte den Eintrag in die ''fstab'' mit dem Befehl {{ic|# mount --all}} testen, da eine fehlerhafte '''fstab''' zu Problemen beim Systemstart führen kann! | |||
== | == Geschwindigkeitsoptimierungen == | ||
Die von SSH genutzte Verschlüsselungsmethode zu weniger rechenintensiven zu ändern, kann die Geschwindigkeit verbessern. Nach diesem Aspekt sind ''Arcfour'' und ''Blowfish-CBC'' die besten Alternativen. Um sie zu benutzen, führt man SSH mit dem '''c'''-Flag aus: | |||
Die von SSH genutzte Verschlüsselungsmethode zu weniger rechenintensiven zu ändern, kann die Geschwindigkeit verbessern. Nach diesem Aspekt sind ''Arcfour'' und ''Blowfish-CBC'' die besten Alternativen. Um sie zu benutzen, | |||
# ssh -c arcfour,blowfish-cbc user@server-address | # ssh -c arcfour,blowfish-cbc user@server-address | ||
Um sie immer zu benutzen, | Um sie immer zu benutzen, fügt man diese Zeile unter dem Punkt "Host" in der '''/etc/ssh/ssh_config''' ein: | ||
Ciphers arcfour,blowfish-cbc | Ciphers arcfour,blowfish-cbc | ||
Zeile 379: | Zeile 188: | ||
alias ssh='ssh -C4c arcfour,blowfish-cbc' | alias ssh='ssh -C4c arcfour,blowfish-cbc' | ||
Man kann alle Verbindungen zu dem selben Host nur eine einzige Verbindung laufen lassen, was einen wahren Geschwindigkeitszuwachs geben sollte. Dafür fügt man folgende Zeilen in die Konfigurationsdatei '''/etc/ssh/ssh_config''' ein: | |||
ControlMaster auto | ControlMaster auto | ||
ControlPath ~/.ssh/socket-%r@%h:%p | ControlPath ~/.ssh/socket-%r@%h:%p | ||
= Problemlösungen = | |||
== | |||
Stelle sicher, dass deine DISPLAY-Variable vom andern Ende der Verbindung auflösbar ist: | Stelle sicher, dass deine DISPLAY-Variable vom andern Ende der Verbindung auflösbar ist: | ||
ssh -X user@server-address | ssh -X user@server-address | ||
server$ echo $DISPLAY | server$ echo $DISPLAY | ||
localhost:10.0 | localhost:10.0 | ||
server$ telnet localhost 6010 | server$ telnet localhost 6010 | ||
localhost/6010: lookup failure: Temporary failure in name resolution | localhost/6010: lookup failure: Temporary failure in name resolution | ||
Wenn dieser Fehler auftaucht, solltest man ''localhost'' zu '''/etc/hosts''' hinzufügen. | |||
Wenn dieser Fehler auftaucht, solltest | |||
== Autologout verhindern == | == Autologout verhindern == | ||
Deine SSH-Session wird nach einiger Zeit beendet, wenn man lange inaktiv war. Um dies zu verhindern, muss folgendes in die '''~/.ssh/config''' oder in die '''/etc/ssh/ssh_config''' geschrieben werden: | |||
Deine SSH-Session wird nach einiger Zeit beendet, wenn | |||
ServerAliveInterval 120 | ServerAliveInterval 120 | ||
Zeile 447: | Zeile 217: | ||
== Sichere Verbindungsdaten in der .ssh/config == | == Sichere Verbindungsdaten in der .ssh/config == | ||
Wann immer du dich zu einem Server verbinden willst, musst du zumindest dessen Adresse und deinen Benutzernamen angeben. Um dir diese Tipparbeit für regelmäßige Verbindungen zu ersparen, kannst du deine '''~/.ssh/config''' benutzen: | Wann immer du dich zu einem Server verbinden willst, musst du zumindest dessen Adresse und deinen Benutzernamen angeben. Um dir diese Tipparbeit für regelmäßige Verbindungen zu ersparen, kannst du deine '''~/.ssh/config''' benutzen: | ||
Host '''myserver''' | Host '''myserver''' | ||
HostName 123.123.123.123 | HostName 123.123.123.123 | ||
Port 12345 | Port 12345 | ||
User bob | User bob | ||
## Falls ein privater Schlüssel vorhanden ist, kann er hier angegeben werden | |||
# IdentityFile ~/.ssh/privater_key | |||
Host other_server | Host other_server | ||
HostName test.something.org | HostName test.something.org | ||
User alice | User alice | ||
# Dies verhindert die Kontrolle der IP des Hosts mit der IP, | |||
# die in ~/.ssh/known_hosts eingetragen wurde. Hilfreich bei | |||
# Hosts hinter dynamischen IPs | |||
CheckHostIP no | CheckHostIP no | ||
Zeile 474: | Zeile 242: | ||
Für eine komplette Liste von Optionen siehe die ssh_config Manpage oder die [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config Documentation] auf der offiziellen Homepage. | Für eine komplette Liste von Optionen siehe die ssh_config Manpage oder die [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config ssh_config Documentation] auf der offiziellen Homepage. | ||
= | == Verbindung zu Hosts mit veralteter Verschlüsselung == | ||
Mit Version 8.8 von OpenSSH ist die Unterstützung von RSA-Signaturen mit SHA1 standardmäßig deaktiviert, da diese Art der Signatur als gebrochen gilt, da sie [https://www.usenix.org/conference/usenixsecurity20/presentation/leurent anfällig für Kollisionsangriffe] {{sprache|en}} ist. Im Regelfall gibt es hier keine Probleme und neue Keys werden mit sichereren Algorithmen generiert. | |||
Sollte man sich zu Servern verbinden müssen, die dies nicht unterstützen und für die man notwendiger Weise RSA mit SHA1 benutzen muss, kann man in {{ic|~/.ssh/config}} für den jeweiligen Host folgenden Abschnitt hinzufügen oder die Optionen bei bestehender Konfiguration für den Host ergänzen. | |||
Host rsassh.example.com | |||
HostkeyAlgorithms +ssh-rsa | |||
PubkeyAcceptedAlgorithms +ssh-rsa | |||
Damit ist die Verbindung wieder möglich. Wenn man nur {{ic|HostkeyAlgorithms +ssh-rsa}} angibt, wird man bei der Verbindung nach dem Passwort gefragt. Wenn man zusätzlich noch {{ic|PubkeyAcceptedAlgorithms +ssh-rsa}} benutzt, ist auch die Anmeldung mit bestehenden Schlüsseln ohne Passwort möglich. | |||
Selbstverständlich sollte man versuchen, den Zielhost soweit zu aktualisieren, dass RSA mit SHA1 nicht mehr notwendig ist. | |||
Mit Version 9.8 von OpenSSH ist unter Arch Linux die Unterstützung von DSA nicht mehr im kompilierten Paket vorhanden. Wenn man dies unbedingt benötigt, muss man das Paket mit der Konfigurationsoption {{ic|--enable-dsa-keys}} selbst kompilieren. | |||
*[http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks] | = Weblinks = | ||
* [http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks] {{sprache|en}} | |||
* [http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch09_02.htm O'Reilly SSH, the secure Shell: the definitive guide, Chapter 9.2 Port Forwarding] {{sprache|en}} | |||
* [https://lists.mindrot.org/pipermail/openssh-unix-announce/2024-July/000158.html Announcement-Mail zu OpenSSH 9.8 und der Deaktivierung von DSA] {{sprache|en}} | |||
[[Kategorie:Artikelstil]] | |||
[[Kategorie:Sicherheit]] | |||
[[Kategorie:Netzwerk]] | |||
[[Kategorie:Server]] | |||
[[en:Secure Shell]] |
Aktuelle Version vom 6. Juli 2024, 19:22 Uhr
Dieser Artikel oder Artikelabschnitt bedarf einer stilistischen Überarbeitung laut Empfehlungen in Artikelstil.
Dieser Artikel wurde als veraltet markiert, und sollte kontrolliert, und gegebenfalls korrigiert bzw. aktualisiert werden.
Secure Shell oder SSH ist ein Netzwerkprotokoll, welches den sicheren Datenaustausch zwischen zwei Computern über ein Netzwerk gestattet. SSH bietet dank Verschlüsselung Diskretion und Integrität der versendeten Daten. Als Verschlüsselungsverfahren wird ein asymmetrisches Kryptosystem (Verschlüsselung durch Public- und Private-Keys) eingesetzt, um den zugreifenden Computer und - falls benötigt - auch den zugreifenden Benutzer zu verifizieren.
SSH wird normalerweise benutzt, um sich in einem entfernten System einzuloggen und Kommandos auszuführen. Zusätzlich werden Tunneling, das Transmission Control Protocol (TCP) und X11 Verbindungen unterstützt. Datentransfer kann durch die Protokolle SFTP und SCP erreicht werden.
Standardmäßig lauscht der SSH-Server auf den Standard-TCP-Port 22. Ein SSH-Client-Programm wird normalerweise zur Herstellung einer Verbindung zu einem sshd (Secure Shell Daemon) benutzt. Beide Programme sind für die meisten modernen Betriebssysteme vorhanden. U.a. für Mac OS X, GNU/Linux, Solaris und OpenVMS. Proprietäre, freie und Open Source Versionen in unterschiedlicher Komplexität und Vollständigkeit existieren.
(Quelle: Secure Shell])
OpenSSH
OpenSSH (OpenBSD Secure Shell) ist eine Sammlung von Programmen, die eine verschlüsselte Verbindung über ein Computernetzwerk mit dem SSH-Protokoll erlauben. Sie wurde als eine Open-Source-Alternative zu der proprietären Secure Shell Software Suite des Unternehmens SSH Communications Security erstellt. OpenSSH wird als Teil des OpenBSD Projektes entwickelt und von Theo de Raadt geleitet.
OpenSSH wird gelegentlich mit dem ähnlich benannten OpenSSL verwechselt. Beide Projekte haben allerdings verschiedene Zwecke und werden von verschiedenen Teams entwickelt. Der ähnliche Name kommt allein von ähnlichen Zielen.
Installation
Das Programm ist als
openssh
in core
verfügbar, und kann von dort
mittels Pacman
installiert werden.
Nach der Installation stehen einige Programme zur Verfügung:
ssh
Ein Programm, mit dem man verschlüsselt auf die Shell entfernter Rechner zugreifen kann, aber auch Verbindungen tunneln kann.scp
Ein Programm, um verschlüsselt Dateien zu übertragen. Es funktioniert ähnlich wiecp
kann jedoch auf Dateien entfernter Rechner zugreifen.ssh-keygen
Mit diesem Programm kann man Schlüssel erstellen, welche die Passwort Authentifizierung auf entfernten Rechnern ersetzen können.ssh-copy-id
Mit diesem Programm können die erstellten Schlüssel für die Authentifizierung einfach und sicher ausgetauscht werden.sshd
Ein Daemon, der verwendet werden kann, um den Computer als entfernten Computer verwenden zu können.
Verwendung
Client ssh
Die SSH-Client-Konfigurationsdatei wird unter /etc/ssh/ssh_config
automatisch angelegt.
Die Standardkonfiguration ist für viele Fälle absolut ausreichend. Um die Sicherheit ein wenig zu erhöhen,
kann die ProtocolVersion auf 2 beschränkt werden. Die Standardeinstellung 2,1 besagt, dass zuerst eine Verbindung
über Version 2 versucht werden soll. Version 1 öffnet einem aktiven Angreifer einige Sicherheitsrelevanten Möglichkeiten wie MITM oder
Datainsertion [1][2].
Mit $ ssh [-p port] [user@]host
wird eine sichere Verbindung zum Server host aufgebaut. Die Angabe von Port und User sind dabei optional. Wird der User weggelassen, so nimmt ssh den aktuellen Benutzernamen für den Verbindungsaufbau.
Beispiele
# ssh root@archlinux.com
Baut eine root Verbindung zum Server archlinux.com auf.# ssh -p 2222 max@192.168.0.2
Baut eine Verbindung zum Computer 192.168.0.2 auf Port 2222 auf und versucht sich dort mit dem Benutzernamen max einzuloggen.# ssh ::1
Baut eine Verbindung zu localhost über IPv6 auf.
Daemon sshd.service
Die Konfigurationsdatei des Daemons /etc/ssh/sshd_config
sollte vor dem Start entsprechend angepasst werden:
AllowUsers user1 user2
schränkt den Zugriff auf die Benutzer user1 und user2 ein.AllowGroups sshusers
schränkt den Zugriff auf Benutzer der Gruppe sshusers ein.Protocol 2
beschränkt den Server lediglich auf die Verwendung von Protocol Version 2.LoginGraceTime 120
bedeutet, dass man nach 120 inaktiven Sekunden automatisch getrennt wird.PermitRootLogin no
verbietet einen direkten Login des Benutzers root. Aufrufe persudo
bleiben davon unberührt.PasswordAuthentication no
Kann benutzt werden, wenn man anstatt Passwörtern nur noch Schlüssel für die Authentifizierung ermöglichen will.ChallengeResponseAuthentication no
ChallengeResponseAuthentication kann sicher implementiert sein. Ist jedoch das Backend falsch konfiguriert, wird hier ebenfalls nur nach dem Passwort gefragt. Es bietet sich daher an, sofern man sich mit PAM aber nur eine Authentifizierung über Schlüssel zulassen möchte zu deaktivieren.ListenAddress ::
Um auch IPv6 Verbindungen zuzulassen.
In der Datei /etc/issue
kann eine Nachricht hinterlassen werden, die bei jedem Login über ssh angezeigt wird.
Der Daemon welcher die Verbindung zu dem Computer zulässt sollte nur gestartet werden, wenn man auf den Computer entfernt zugreifen möchte.
Der Name des Services ist sshd.service
und kann wie üblich über # systemctl
konfiguriert werden.
# systemctl enable sshd.service # systemctl {start|stop|restart} sshd.service
Schlüsselgenerierung ssh-keygen und ssh-id-copy
#ssh-keygen -t rsa
Erzeugt einen privaten und einen öffentlichen Schlüssel. Normal werden diese in /home/user/.ssh/id_rsa
und /home/user/.ssh/id_rsa.pub
abgelegt. Der private Schlüssel id_rsa
sollte niemals in fremde Hände geraten, da er für die Authentifizierung auf allen konfigurierten Systemen ermöglicht! Der öffentliche Schlüssel kann auf einen SSH-Server mit folgendem Befehl installiert werden um sich anschließend ohne Passwort einzuloggen:
# ssh-copy-id -i /home/user/.ssh/id_rsa.pub user@host
Weitere Infos findet man in dem Artikel SSH-Authentifizierung mit Schlüsselpaaren.
Dateiübertragung scp
Der Befehl scp
funktioniert im wesentlichen genau wie cp
jedoch können Ziel und Quelldateien auf verschiedenen über SSH zugänglichen Computern liegen. Am besten versteht man scp
an einigen Beispielen:
scp mypicture.png max@mustermannserver.net:/home/max/mypicture.png
Überträgt die Datei mypicture.png auf den mustermannserver in /home/max/. Dabei wird der Benutzer max zur Authentifizierung am Zielserver verwendet.scp max@mustermannserver.net:/home/max/mypicture.png ./mypicture.png
Kopiert die Datei vom mustermannserver zum lokalen Computerscp root@server1:/etc/fstab root@server2:/etc/fstab
überträgt die fstab Datei von Server1 nach Server2.
Natürlich können auch ganze Verzeichnisse kopiert werden oder rekursive Befehle genutzt werden. Dabei geht man exakt so vor wie bei cp.
Tipps und Tricks
Verschlüsselter Socks4 Proxy
Ein Rechner, auf dem ein SSH-Daemon läuft zu dem man einen Zugang hat, kann verschlüsselt als Proxy verwendet werden. Das bedeutet man kann alle Verbindungen verschlüsselt über diesen Computer weiterleiten. Dies kann für mehrere Szenarien verwendet werden:
- Gateway Zugang zu einem Firmennetz
- Sicherer Internetzugang in einem unverschlüsselten oder unsicheren WLAN
- Anonymisierung im Internet
- Sichere Verbindung zweier entfernter Firmenstandorte
Achtung: Die Verbindung wird nicht bis zum Zielrechner verschlüsselt, sondern nur bis zum SSH Server!
$ ssh -ND localhost:8080 user@host
Dieser Befehl öffnet auf dem Lokalen Computer den Port 8080 als Socks4 Proxyverbindungen. Dazu wird der Computer host als Proxy verwendet. Die Einschränkung localhost besagt dabei, dass nur der lokale Computer eine Verbindung zum Port 8080 aufbauen darf. Man kann hier auch einen IP Bereich angeben und so anderen Computern im lokalen Netzwerk ermöglichen den Tunnel zu benutzen. Die Verbindung wird für user authentifiziert und danach der lokale Proxyport freigegeben. Die Wahl des Ports 8080 kann beliebig erfolgen. Alle Programme die den Tunnel nutzen sollen, müssen auf diesen Port konfiguriert werden. Der Parameter N besagt lediglich, dass keine Eingabeaufforderung aktiv werden soll und D ist für das öffnen des Ports verantwortlich.
Um den Aufwand zu reduzieren kann man einen alias in ~/.bashrc hinzuzufügen:
alias sshtunnel="ssh -ND localhost:8080 -v user@host"
Das v-Flag (für verbose - gesprächig) wird hinzugefügt, damit man an den Ausgaben erkennen kann ob die Verbindung aufgebaut wurde.
Achtung: Nur Programme bei denen ein Socks4 Proxy auf localhost:8080 konfiguriert wurde benutzen diesen verschlüsselten Tunnel. Alle anderen Programme schicken ihre Pakete nach wie vor direkt auf den Weg!
X11 weiterreichen
Um grafische Programme durch eine SSH-Verbindung zu benutzen, muss man das Weiterreichen von X11 aktivieren. Damit können Programme entfernt ausgeführt jedoch die graphische Oberfläche lokal angezeigt werden. Man installiert dazu das Paket xorg-xauth
auf dem Server und ändert folgende Einstellungen
- Aktiviere die AllowTcpForwarding Option in der sshd_config auf deinem Server.
- Aktiviere die X11Forwarding Option in der sshd_config auf deinem Server.
- Ändere die X11DisplayOffset Option in der sshd_config auf deinem Server auf 10.
- Aktiviere die X11UseLocalhost Option in der sshd_config auf deinem Server.
- Aktiviere die ForwardX11 Option in der ssh_config auf deinem Client.
Um die Verbindung zum X11 aufzubauen fügt man X oder Y (für sicheres Verbinden) beim Verbindungsaufbau hinzu:
# ssh -X[Y] -p port user@host
Startet man nun ein grafisches Programm wie xclock
in der Eingabeaufforderung so wird die Anwendung auf host gestartet, die GUI erscheint jedoch lokal.
Port Weiterleitung mit SSH
SSH erlaubt es auch einzelne Ports verschlüsselt zu verknüpfen. Dazu können alle Verbindungen auf einem Quellport zu einem Zielport über einen konkreten Rechner weitergeleitet werden.
ssh -g -L 120:ZIEL:80 user@host
Dieser Befehl öffnet einen lokalen Port (120) und leitet alle Verbindungen auf diesem Port über host zum Port 80 auf Ziel weiter.
ssh -g -L8080:192.168.0.23:80 user@sshgateway.firma.net
- 192.168.23 ist dabei z.B. ein Webserver der auf Port 80 im lokalen Netzwerk von firma.net hört.
- Öffnet man nun http://localhost:8080, so werden die Daten an den sshgateway.firma.net weitergeleitet, welche die Zustellung an 192.168.23 übernimmt.
Achtung: Falsch konfigurierte SSH-Gateways können ganze Firmennetze kompromittieren!
Man kann den Parameter -L mehrmals verwenden:
ssh -g -L8080:192.168.0.23:80 -L8081:192.168.0.24:80 user@sshgateway.firma.net
Nutzen man statt dem Schalter "-L" den Schalter "-R", so wird aus der Lokalen Weiterleitung eine Remote Weiterleitung. Man kann damit dem Zielrechner die Verwendung eines lokalen Services ermöglichen.
Ein entferntes Filesystem mit SSHFS mounten
Zuerst muss SSHFS installiert und das fuse-Modul geladen werden. Wie man das fuse Modul automatisch lädt kann dem Artikel Kernelmodule entnommen werden.
# pacman -S sshfs # modprobe fuse
Um nun einen entfernten Ordner zu mounten, erstellt man einen Ordner und verlinkt diesen über sshfs:
- mkdir ~/remote_folder
- sshfs USER@remote_server:/path/to/folder ~/remote_folder
Das Kommando oben wird den Ordner /tmp auf dem Server in den Ordner ~/remote_folder auf deinem lokalen Computer einhängen. Schreibvorgänge in diesem Ordner werden per SFTP ausgeführt. Mit #fusermount -u ~/remote_folder
kann das entfernte Verzeichnis wieder ausgehängt werden.
Möchte man einen Eintrag in die fstab machen um das Verzeichnis automatisch beim Systemstart einzuhängen, fügt man folgende Zeile in /etc/fstab
ein:
sshfs USER@remote_server:/path/to/source /path/to/target fuse defaults,auto,allow_other 0 0
Dabei gibt /path/to/source
das Verzeichnis auf dem Server und /path/to/target
das lokale Verzeichnis an. Man sollte den Eintrag in die fstab mit dem Befehl # mount --all
testen, da eine fehlerhafte fstab zu Problemen beim Systemstart führen kann!
Geschwindigkeitsoptimierungen
Die von SSH genutzte Verschlüsselungsmethode zu weniger rechenintensiven zu ändern, kann die Geschwindigkeit verbessern. Nach diesem Aspekt sind Arcfour und Blowfish-CBC die besten Alternativen. Um sie zu benutzen, führt man SSH mit dem c-Flag aus:
# ssh -c arcfour,blowfish-cbc user@server-address
Um sie immer zu benutzen, fügt man diese Zeile unter dem Punkt "Host" in der /etc/ssh/ssh_config ein:
Ciphers arcfour,blowfish-cbc
Eine andere Option, die die Geschwindigkeit verbessern kann, ist das Einschalten der Kompression mit dem C-Flag. Eine dauerhafte Lösung ist es, folgende Zeile unter dem Punkt "Host" in deiner /etc/ssh/ssh_config hinzuzufügen:
Compression yes
Die Login-Zeit kann reduziert werden, wenn das 4-Flag benutzt wird. Dieses schaltet IPv6 aus. Die dauerhafte Lösung in diesem Fall ist es, folgende Zeile unter dem Punkt "Host" in deiner /etc/ssh/ssh_config hinzuzufügen:
AddressFamily inet
Ein anderer Weg um diese Änderungen dauerhaft zu machen ist, einen Alias in der ~/.bashrc (oder dem Gegenstück von anderen Shells) zu erstellen:
alias ssh='ssh -C4c arcfour,blowfish-cbc'
Man kann alle Verbindungen zu dem selben Host nur eine einzige Verbindung laufen lassen, was einen wahren Geschwindigkeitszuwachs geben sollte. Dafür fügt man folgende Zeilen in die Konfigurationsdatei /etc/ssh/ssh_config ein:
ControlMaster auto ControlPath ~/.ssh/socket-%r@%h:%p
Problemlösungen
Stelle sicher, dass deine DISPLAY-Variable vom andern Ende der Verbindung auflösbar ist:
ssh -X user@server-address server$ echo $DISPLAY localhost:10.0 server$ telnet localhost 6010 localhost/6010: lookup failure: Temporary failure in name resolution
Wenn dieser Fehler auftaucht, solltest man localhost zu /etc/hosts hinzufügen.
Autologout verhindern
Deine SSH-Session wird nach einiger Zeit beendet, wenn man lange inaktiv war. Um dies zu verhindern, muss folgendes in die ~/.ssh/config oder in die /etc/ssh/ssh_config geschrieben werden:
ServerAliveInterval 120
Dies sendet alle 120 Sekunden ein "keep alive"-Signal zu dem Server.
Natürlich kannst du auch eingehende Verbindungen lebendig halten. Füge dafür folgendes deiner /etc/ssh/sshd_config auf dem Server hinzu:
ClientAliveInterval 120
Sichere Verbindungsdaten in der .ssh/config
Wann immer du dich zu einem Server verbinden willst, musst du zumindest dessen Adresse und deinen Benutzernamen angeben. Um dir diese Tipparbeit für regelmäßige Verbindungen zu ersparen, kannst du deine ~/.ssh/config benutzen:
Host myserver HostName 123.123.123.123 Port 12345 User bob ## Falls ein privater Schlüssel vorhanden ist, kann er hier angegeben werden # IdentityFile ~/.ssh/privater_key Host other_server HostName test.something.org User alice # Dies verhindert die Kontrolle der IP des Hosts mit der IP, # die in ~/.ssh/known_hosts eingetragen wurde. Hilfreich bei # Hosts hinter dynamischen IPs CheckHostIP no Cipher blowfish
Nun musst du nur den Namen des Servers eingeben, um dich mit ihm zu verbinden:
$ ssh myserver
Für eine komplette Liste von Optionen siehe die ssh_config Manpage oder die ssh_config Documentation auf der offiziellen Homepage.
Verbindung zu Hosts mit veralteter Verschlüsselung
Mit Version 8.8 von OpenSSH ist die Unterstützung von RSA-Signaturen mit SHA1 standardmäßig deaktiviert, da diese Art der Signatur als gebrochen gilt, da sie anfällig für Kollisionsangriffe ist. Im Regelfall gibt es hier keine Probleme und neue Keys werden mit sichereren Algorithmen generiert.
Sollte man sich zu Servern verbinden müssen, die dies nicht unterstützen und für die man notwendiger Weise RSA mit SHA1 benutzen muss, kann man in ~/.ssh/config
für den jeweiligen Host folgenden Abschnitt hinzufügen oder die Optionen bei bestehender Konfiguration für den Host ergänzen.
Host rsassh.example.com HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
Damit ist die Verbindung wieder möglich. Wenn man nur HostkeyAlgorithms +ssh-rsa
angibt, wird man bei der Verbindung nach dem Passwort gefragt. Wenn man zusätzlich noch PubkeyAcceptedAlgorithms +ssh-rsa
benutzt, ist auch die Anmeldung mit bestehenden Schlüsseln ohne Passwort möglich.
Selbstverständlich sollte man versuchen, den Zielhost soweit zu aktualisieren, dass RSA mit SHA1 nicht mehr notwendig ist.
Mit Version 9.8 von OpenSSH ist unter Arch Linux die Unterstützung von DSA nicht mehr im kompilierten Paket vorhanden. Wenn man dies unbedingt benötigt, muss man das Paket mit der Konfigurationsoption --enable-dsa-keys
selbst kompilieren.