SSH

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page SSH and the translation is 100% complete.
Other languages:
Deutsch • ‎English • ‎español • ‎français • ‎italiano • ‎русский • ‎中文(中国大陆)‎ • ‎日本語 • ‎한국어
Resources

SSH (Secure SHell) ist ein verschlüsseltes Terminal-Programm, dass das klassische telnet-Tool auf unixoiden Betriebssystemen ersetzt.

Zusätzlich zum Terminal-Fernzugriff, welcher durch das Hauptprogramm ssh bereitgestellt wird, enthält die SSH-Programmsammlung inzwischen auch andere Werkzeuge wie scp (secure copy) oder sftp (secure file transfer protocol).

Ursprünglich war SSH nicht frei. Heute ist die populärste und de-facto Standard-Implementation OpenBSD's OpenSSH, welche bei Gentoo vorinstalliert ist.

Installation

Installation überprüfen

Die meisten Bereitstellungen von Gentoo Linux haben OpenSSH bereits auf dem System installiert. Dies kann durch Ausführen des ssh-Befehls überprüft werden. Sofern es installiert ist sollte eine Gebrauchsanweisung ausgegeben werden:

user $ssh
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-E log_file] [-e escape_char]
           [-F configfile] [-I pkcs11] [-i identity_file]
           [-L [bind_address:]port:host:hostport] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-p port]
           [-Q cipher | cipher-auth | mac | kex | key]
           [-R [bind_address:]port:host:hostport] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] [user@]hostname [command]

Wenn keine Gebrauchsanweisung ausgegeben wird ist ssh entweder beschädigt oder nicht installiert. Es ist auch möglich dass ein Nutzer OpenSSH neu baut um eine neue USE-Konfiguration zu inkludieren. Wie auch immer, zum Betrachten von möglichen USE-Konfigurationen weitermachen.

USE-Flags

USE flags for net-misc/openssh Port of OpenBSD's free SSH release

X Add support for X11
X509 Adds support for X.509 certificate authentication
audit Enable support for Linux audit subsystem using sys-process/audit
bindist Disable EC/RC5 algorithms in OpenSSL for patent reasons.
debug Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
hpn Enable high performance ssh
kerberos Add kerberos support
ldns Use LDNS for DNSSEC/SSHFP validation.
libedit Use the libedit library (replacement for readline)
livecd Enable root password logins for live-cd environment.
pam Add support for PAM (Pluggable Authentication Modules)DANGEROUS to arbitrarily flip
pie Build programs as Position Independent Executables (a security hardening technique)
scp Enable scp command with known security problems. See bug 733802
sctp Support for Stream Control Transmission Protocol
security-key Include builtin U2F/FIDO support
selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
ssl Enable additional crypto algorithms via OpenSSL
static !!do not set this during bootstrap!! Causes binaries to be statically linked instead of dynamically
test Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)
xmss Enable XMSS post-quantum authentication algorithm

Emerge

Nach dem Ändern der notwendigen USE-Flags das Installieren oder Neubauen von OpenSSH nicht vergessen:

root #emerge --ask --changed-use net-misc/openssh

Konfiguration

Schlüssel erstellen

Um eine sichere Shell bereitzustellen, werden kryptographische Schlüssel für die Ver- und Entschlüsselung sowie Hashing-Funktionen von SSH benutzt.

Beim ersten Start des SSH-Services werden die System-Schlüssel erzeugt. Diese können mittels des ssh-keygen-Befehls (neu-)erstellt werden .

Um die Schlüssel für das SSH-Protokoll Version 2 zu erzeugen (DSA und RSA Algorithmen):

root #/usr/bin/ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ""
root #/usr/bin/ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ""

Der Artikel Secure Secure Shell empfiehlt die Benutzung von Ed25519 und RSA als Algorithmen für den öffentlichen Schlüssel mit:

root #/usr/bin/ssh-keygen -t ed25519 -a 100 -f /etc/ssh/ssh_host_ed25519_key -N ""
root #/usr/bin/ssh-keygen -t rsa -b 4096 -o -a 100 -f /etc/ssh/ssh_host_rsa_key -N ""

Server-Konfiguration

Der SSH Server wird normalerweise in der Datei /etc/ssh/sshd_config konfiguriert, weitere Einstellungen, einschließlich des Ortes, an dem sich die obige Konfiguration befindet, können in /etc/conf.d/sshd getätigt werden, inklusive das Ändern des Ortes der Konfigurationsdatei. Für Details über die Konfiguration sollte die man page "sshd_config" konsultiert werden.

Benutzer sollten für eine sicherheitsfokussierte Konfiguration Sven Vermeulen (SwifT)s OpenSSH-Anleitung studieren.

Der Server stellt eine Möglichkeit zur Validierung seiner Konfiguration durch den Testmodus zur Verfügung.

root #/usr/sbin/sshd -t
Wichtig
Befor der Dienst neugestartet wird, sollte die Konfiguration immer validiert werden, damit der Fernzugriff verfügbar bleibt.

Klient-Konfiguration

Der ssh-Klient und zugehörige Programme (scp, sftp, etc.) können in den folgenden Dateien konfiguriert werden:

  • ~/.ssh/config
  • /etc/ssh/ssh_config

Für weitere Information das ssh_config-Handbuch lesen:

user $man ssh_config

Eindringensvermeidung

SSH ist ein oft angegriffener Dienst. Werkzeuge wie sshguard und fail2ban überwachen Logs und blacklisten entfernte Nutzer die wiederholt versuchten und scheiterten, sich anzumelden. Wie benötigt verwenden um ein häufig attackiertes System abzusichern.

Bedienung

Den SSH-Server starten

OpenRC

Den OpenSSH-Daemon zum Default-Runlevel hinzufügen:

root #rc-update add sshd default

Den sshd-Daemon starten mit:

root #rc-service sshd start

Der OpenSSH-Server kann wie jeder andere OpenRC-Dienst gesteuert werden:

root #rc-service sshd start
root #rc-service sshd stop
root #rc-service sshd restart
Notiz
Aktive Verbindungen zum Server bleiben beim Ausführen von rc-service sshd restart intakt.

systemd

Um den OpenSSH-Daemon mit dem System zu starten:

root #systemctl enable sshd.service
Hat einen symbolischen Verweis von /etc/systemd/system/multi-user.target.wants/sshd.service auf /usr/lib64/systemd/system/sshd.service angelegt.

Um den OpenSSH-Daemon jetzt zu starten:

root #systemctl start sshd.service

Um zu überprüfen ob der Dienst gestartet wurde:

root #systemctl status sshd.service

Ausbruchsequenzen

Während einer aktiven SSH-Sitzung wird durch das Drücken der Tile-Taste (~) eine Ausbruchsequenz begonnen:

ssh>~?

Verbindung zu einem entfernten SSH-Server aufbauen

Passwortlose Authentifizierung

Praktisch für das Verwalten von git-Servern.

Klient

Falls noch nicht vorhanden, muss auf dem Klienten ein Schlüsselpaar angelegt werden. Dies erfolgt durch die Eingabe des folgenden Befehls (natürlich ohne eine Passphrase einzugeben):

user $ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/larry/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/larry/.ssh/id_rsa.
Your public key has been saved in /home/larry/.ssh/id_rsa.pub.
The key fingerprint is:
de:ad:be:ef:15:g0:0d:13:37:15:ad:cc:dd:ee:ff:61 larry@client
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|     .           |
| . .. n   .      |
|   . (: . .      |
|  o   . . : .    |
| . ..: >.> .     |
|  * ?. .         |
| o.. .. ..       |
| :. .  ! .       |
+-----------------+

Server

Nun muss sichergestellt werden, dass für den Anwender ein Benutzerkonto auf dem Server existiert. Dann kann der Inhalt der id_rsa.pub-Datei des Klienten in der Datei ~/.ssh/authorized_keys im Homeverzeichnis des Anwenders auf dem Server platziert werden. Dies erfolgt durch das Ausführen des folgenden Befehls auf dem Klienten (ess wird die Passphrase des Anwenders auf dem Server benötigt):

user $ssh-copy-id <server>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/larry/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
larry@<server>'s password: 

Number of key(s) added: 1

Nun kann eine Anmeldung am System mit "ssh '<server>'" versuchs werden, um zu überprüfen, ob nur die Schlüssel hinzugefügt wurden, die vorgesehen waren.

Anschließend sollte eine Anmeldung ohne Eingabe der Passphrase wie folgt möglich sein:

{{cmd|ssh <server>|output=<pre>larry@<server>

Auf dem Server sollte dann in der Datei /etc/ssh/sshd_config PasswordAuthentication no eingetragen werden.

Einzel-Maschinen-Test

Die oben beschriebene Prozedur kann lokal getestet werden:

user $ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/larry/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
...
user $mv ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys
user $ssh localhost

Fehlersuche

Es gibt drei verschiedene Level von Debug-Modi, die bei der Problemlösung helfen können. Mit der -v-Option gibt SSH Debugging-Nachrichten über seinen Fortschritt aus. Dies ist hilfreich bei dem Debugging von Verbindungs-, Authentifikations- und Konfigurationsproblemen. Mehrfache -v-Optionen erhöhen die Verbosität. Das Maximum ist drei.

user $ssh example.org -v
user $ssh example.org -vv
user $ssh example.org -vvv

Abbruch langlebiger Verbindungen

Viele Geräte, die Zugriff zum Internet anbieten, benutzen dafür Network Address Translation (NAT), ein Prozess der Geräten in einem privaten Netzwerk (typischerweise in Heim- oder Berufsumgebungen) Zugriff auf fremde Netzwerke wie dem Internet ermöglicht, obwohl sie nur eine einzige IP-Adresse in diesem fremden Netzwerk besitzt. Leider funktionieren diese NAT-Geräte nicht alle gleich und manche von ihnen schließen langlebige, nur gelegentlich genutzte TCP Verbindungen wie die von SSH. Man erkennt das daran, dass man auf einmal nicht mehr mit dem entfernten Computer interagieren kann, obwohl das ssh-Klienten-Programm nicht beendet wurde.

Um dieses Problem zu lösen, können OpenSSH-Klienten und -Server so konfiguriert werden, dass sie eine unsichtbare "keep alive" Nachricht senden, deren Ziel das Aufrechterhalten der Verbindung ist:

  • Um Keep-Alive für alle Klienten, die sich mit dem lokalen Server verbinden, zu aktivieren, ClientAliveInterval 30 (oder einen anderen Wert, in Sekunden) in der /etc/ssh/sshd_config-Datei setzen.
  • Um Keep-Alive für alle Server, mit denen sich der lokale Klient verbindet, zu aktivieren, ClientAliveInterval 30 (oder einen anderen Wert, in Sekunden) in der /etc/ssh/ssh_config-Datei setzen.

X11-Weiterleitung, keine Portweiterleitung oder Tunnelung

Problem: Nachdem die nötigen Veränderungen an den Konfigurationsdateien gemacht sind, wird bemerkt dass X-Applikationen auf dem Server ausgeführt und nicht an den Klienten weitergeleitet werden.

Lösung: Was vermutlich während der SSH-Anmeldung auf dem Server passiert, die DISPLAY-Variable ist entweder nicht gesetzt oder wird gesetzt nachdem die SSH-Sitzung sie setzt.

Wenn das Szenario zutrifft, kann es wie folgend nach dem Anmelden auf dem Server getestet werden:

user $echo $DISPLAY
localhost:10.0

Die Ausgabe sollte in etwa ähnlich zu localhost:10.0 oder localhost2.local:10.0 mit der serverseitigen Einstellung X11UseLocalhost no sein. Wenn das übliche :0.0 nicht ausgegeben wird, sicherstellen dass die DISPLAY-Variable in ~/.bash_profile nicht ungesetzt oder reinitialisiert ist. Wenn sie es ist, jegliche Initialisierung der DISPLAY-Variable entfernen oder auskommentieren um die Ausführung des Codes in ~/.bash_profile bei einer SSH-Anmeldung zu verhindern:

user $ssh -t larry@localhost2 bash --noprofile

larry im Kommando oberhalb mit dem passenden Benutzernamen ersetzen.

Ein Trick der funktioniert wäre ein alias innerhalb der ~/.bashrc-Datei zu definieren.

ssh-agent

OpenSSH enthält ssh-agent, einen Dienst, der für SSH verwandte Passphrasen zwischenspeichert, sodass keine erneute Eingabe erforderlich ist. Wenn er ausgeführt wird, zeigt die Variable SSH_AUTH_SOCK auf sein Kommunikations-Socket. Der übliche Weg zur Einrichtung von ssh-agent ist es, ihn als Wurzelprozess in der Sitzung des Benutzers auszuführen. Andernfalls sind Umgebungsvariablen in der Sitzung nicht abrufbar.

Je nachdem, wie die graphische Benutzersitzung gestartet wird, kann es schwierig sein, einen adäquaten Weg zu finden, ssh-agent zu starten. Als Beispiel für den Displaymanager lightdm kann der Inhalt der Datei /etc/lightdm/Xsession

user $exec $command

durch Folgendes ersetzt werden:

user $exec ssh-agent $command

Um ssh-agent die Passphrase einmal pro Sitzung mitzuteilen, kann entweder ssh-add manuell ausgeführt, oder die Option AddKeysToAgent verwendet werden.

Neuere Versionen von Xfce[1] starten ssh-agent (und gpg-agent) automatisch. Sind beide Programme installiert, werden sie auch beide gestartet, was das Identitätsmanagement insbesondere mit SmartCards erschwert. Um das zu beheben, kann der Autostart des SSH-Agents deaktiviert werden. Alternativ kann auch der Autostart beider Programme deaktiviert werden, um stattdessen die Shell, X-Session oder Ähnliches zu benutzen.

user $xfconf-query -c xfce4-session -p /startup/ssh-agent/enabled -n -t bool -s false
user $xfconf-query -c xfce4-session -p /startup/gpg-agent/enabled -n -t bool -s false

Siehe auch

Externe Ressourcen