This is Gentoo's testing wiki. It is a non-operational environment and its textual content is outdated.

Please visit our production wiki at https://wiki.gentoo.org

SSH

From Gentoo Wiki (test)
Jump to:navigation Jump to:search
This page is a translated version of the page SSH and the translation is 86% complete.
Outdated translations are marked like this.
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

audit Enable support for Linux audit subsystem using sys-process/audit
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
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)
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)
verify-sig Verify upstream signatures on distfiles
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 ""

The article Secure Secure Shell suggests using Ed25519 and RSA public key algorithms with:

root #/usr/bin/ssh-keygen -t ed25519 -a 100 -f /etc/ssh/ssh_host_dsa_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's OpenSSH guide studieren.

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

Passwortlose Authentifizierung

Praktisch für das Verwalten von git-Servern.

Klient

Auf dem Klienten folgenden Befehl ausführen:

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

Sicherstellen dass ein Konto für den Nutzer auf dem Server existiert und dann die Klienten-id_rsa.pub-Datei in der ~/.ssh/authorized_keys-Datei des Servers im Heimverzeichnis des Nutzers platzieren.

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

Now try logging into the machine, with:   "ssh '<server>'"
and check to make sure that only the key(s) you wanted were added.

Afterwards a passwordless login should be possible doing

user $ssh <server>
larry@<server>

Then on the server, the file /etc/ssh/sshd_config should be set to PasswordAuthentication no.

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

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

Dienste

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
Created symlink from /etc/systemd/system/multi-user.target.wants/sshd.service to /usr/lib64/systemd/system/sshd.service.

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

Escape sequences

During an active SSH session, pressing the tilde (~) key starts an escape sequence. Enter the following for a list of options:

ssh>~?

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.

Siehe auch

  • Den SSH-Dienst absichern im Gentoo Sicherheits-Handbuch
  • Gentoo Linux Keychain Guide
  • autossh - Detektiert wenn SSH-Verbindungen abbrechen und verbindet erneut.
  • SCP - Ein Secure-Copy-Programm das in der SSH-Suite enthalten ist.
  • SFTP - Secure-File-Transfer-Protocol-Klient der in der SSH-Suite enthalten ist.
  • SSHFS - Ein FUSE- und SSH-basierter Mount-Klient.

Externe Ressourcen