sshd —
OpenSSH-Daemon
sshd
[
-46DdeiqTtV]
[
-C Verbindungsfestlegung]
[
-c Rechnerzertifikatsdatei]
[
-E Protokolldatei]
[
-f Konfigurationsdatei]
[
-g Anmeldeaufschubzeit]
[
-h Rechnerschlüsseldatei]
[
-o Option]
[
-p Port]
[
-u Länge]
sshd (OpenSSH Daemon) ist das Daemon-Programm
für
ssh(1). Es stellt eine sichere
verschlüsselte Kommunikation zwischen zwei nicht
vertrauenswürdigen Rechnern über ein unsicheres Netzwerk bereit.
sshd wartet auf Anfragen von Clients. Es wird
normalerweise beim Systemstart mittels
/etc/init.d/ssh gestartet. Es erstellt mit Fork
einen neuen Deamon für jede Verbindung. Der mit Fork erstellte Daemon
handhabt den Schlüsselaustausch, die Verschlüsselung,
Authentifizierung, die Befehlsausführung und den Datenaustausch.
sshd kann mittels Befehlszeilenoptionen oder einer
Konfigurationsdatei (standardmäßig
sshd_config(5)) konfiguriert werden;
Befehlszeilenoptionen setzen die in der Konfigurationsdatei gesetzten Werte
außer Kraft.
sshd liest seine
Konfigurationsdatei neu, wenn er ein Auflegen-Signal,
SIGHUP, erhält, indem er sich selbst
mit dem Namen und den Optionen ausführt, mit denen er gestartet wurde,
z.B.
/usr/sbin/sshd.
Folgende Optionen stehen zur Verfügung:
- -4
- Erzwingt, dass sshd nur
IPv4-Adressen verwendet.
- -6
- Erzwingt, dass sshd nur
IPv6-Adressen verwendet.
-
-C
Verbindungsfestlegung
- Legt die Verbindungsparameter fest, die für den
erweiterten Testmodus -T verwandt werden
sollen. Falls bereitgestellt, werden alle Direktiven
Match in der Konfigurationsdatei, die
angewandt würden, angewandt, bevor die Konfigurationsdatei auf die
Standardausgabe geschrieben wird. Die Verbindungsparameter werden als
Schlüsselwort=Wert-Paare bereitgestellt und können in
beliebiger Reihenfolge angegeben werden, entweder mit mehreren
-C -Optionen oder als Kommata-getrennte
Liste. Die Schlüsselwörter sind »addr«,
»user«, »host«, »laddr«,
»lport« und »rdomain« und entsprechen der
Quelladresse, dem Benutzer, dem aufgelösten Quellrechnernamen, der
lokalen Adresse, der lokalen Port-Nummer bzw. der Routing-Domain.
-
-c
Rechnerzertifikatsdatei
- Legt den Pfad zu einer Zertifikatsdatei fest, um
sshd während des
Schlüsselaustausches zu identifizieren. Die Zertifikatsdatei muss
auf eine Rechnerschlüsseldatei passen, die mit der Option
-h oder der Konfigurationsdirektive
HostKey festgelegt wird.
- -D
- Wenn diese Option angegeben ist, wird sich
sshd nicht abtrennen und kein Daemon werden.
Dies erlaubt das einfache Überwachen von
sshd.
- -d
- Fehlersuchmodus. Der Server schickt ausführliche
Fehlersuchausgaben auf die Standardfehlerausgabe und legt sich selbst
nicht in den Hintergrund. Der Server wird auch kein
fork(2) durchführen und nur eine
Verbindung verarbeiten. Diese Option ist nur zur Fehlersuche im Server
gedacht. Mehrere Optionen -d erhöhen
die Fehlersuchstufe. Maximum ist 3.
-
-E
Protokolldatei
- Hängt Fehlersuchprotokolle an
Protokolldatei statt an das
Systemprotokoll an.
- -e
- Schreibt Fehlersuchprotokolle in die Standardfehlerausgabe
statt in das Systemprotokoll.
-
-f
Konfigurationsdatei
- Gibt den Namen der Konfigurationsdatei an. Die Vorgabe ist
/etc/ssh/sshd_config.
sshd verweigert den Start, falls es keine
Konfigurationsdatei gibt.
-
-g
Anmeldeaufschubzeit
- Gibt die Aufschubzeit an, die Clients für die
Authentifizierung haben (standardmäßig 120 Sekunden). Falls
es dem Client nicht gelingt, sich innerhalb der angegebenen Sekunden zu
authentifizieren, löst der Server die Verbindung und beendet sich.
Ein Wert von 0 zeigt an, dass es keine Begrenzung geben soll.
-
-h
Rechnerschlüsseldatei
- Gibt eine Datei an, aus der der Rechnerschlüssel
gelesen wird. Diese Option muss angegeben werden, falls
sshd nicht als root ausgeführt wird
(da die normalen Rechnerschlüsseldateien normalerweise nur von root
lesbar sind). Die Vorgabe ist
/etc/ssh/ssh_host_ecdsa_key,
/etc/ssh/ssh_host_ed25519_key und
/etc/ssh/ssh_host_rsa_key. Es ist
möglich, für die einzelnen
Rechnerschlüsselalgorithmen jeweils mehrere
Rechnerschlüsseldateien zu haben.
- -i
- Gibt an, dass sshd von
inetd(8) ausgeführt wird.
-
-o
Option
- Kann dazu verwandt werden, Optionen im Format der
Konfigurationsdatei anzugeben. Dies ist für Optionen
nützlich, für die es keinen separaten Befehlszeilenschalter
gibt. Für die vollständigen Details dieser Optionen und
ihrer Werte siehe sshd_config(5).
-
-p
Port
- Legt den Port fest, auf dem der Server auf Anfragen wartet
(standardmäßig 22). Mehrere Port-Optionen sind erlaubt. In
der Konfiguration mittels der Option Port
festgelegte Ports werden ignoriert, wenn ein Port auf der Befehlszeile
angegeben wird. Ports, die mit der Option
ListenAddress festgelegt werden, setzen auf
der Befehlszeile angegebene außer Kraft.
- -q
- Stiller Modus. Es wird nichts an das Systemprotokoll
gesandt. Normalerweise wird der Beginn, die Authentifizierung und die
Beendigung jeder Verbindung protokolliert.
- -T
- Erweiterter Testmodus. Prüft die Gültigkeit
der Konfigurationsdatei, gibt die wirksame Konfiguration auf der
Standardausgabe aus und beendet sich. Optional können die
Match -Regeln angewandt werden, indem die
Verbindungsparameter mittels einer oder mehrere Optionen
-C angegeben werden.
- -t
- Testmodus. Prüft nur die Gültigkeit der
Konfigurationsdatei und die Plausibilität der Schlüssel.
Dies ist zur zuverlässigen Aktualisierung von
sshd nützlich, da sich
Konfigurationsoptionen ändern könnten.
-
-u
Länge
- Diese Option wird dazu verwandt, die Größe
des Feldes in der Struktur utmp
festzulegen, die den Namen des fernen Rechners enthält. Falls der
aufgelöste Rechnername die angegebene
Länge überschreitet, wird
stattdessen der gepunktete Dezimalwert verwandt. Dies erlaubt es, Rechner
mit sehr langen Rechnernamen, bei denen dieser Wert
überläuft, weiterhin eindeutig zu identifizieren. Die
Festlegung von -u0 zeigt an, dass nur
gepunktete Dezimaladressen in die Datei utmp
abgelegt werden sollen. -u0 kann auch dazu
verwandt werden, sshd an der
Durchführung von DNS-Anfragen zu hindern, außer der
Authentifizierungsmechanismus oder die Konfiguration verlangt dies.
HostbasedAuthentication und die Verwendung
der Option from="Musterliste"
gehören zu den Authentifizierungsmechanismen, die DNS
benötigen. Die Verwendung eines BENUTZER@RECHNER-Musters in
AllowUsers oder
DenyUsers gehört zu den
Konfigurationsoptionen, die DNS benötigen.
- -V
- Zeigt die Version an und beendet das Programm.
Der OpenSSH-SSH-Daemon unterstützt nur SSH-Protokoll 2. Jeder Rechner
verfügt über einen Rechner-spezifischen Schlüssel, der
diesen Rechner identifiziert. Jedes Mal, wenn sich ein Client verbindet,
antwortet der Daemon mit seinem öffentlichen Rechnerschlüssel.
Der Client vergleicht den Rechnerschlüssel mit seiner eigenen
Datenbank, um sicherzustellen, dass er sich nicht geändert hat. Durch
eine Diffie-Hellman-Schlüsselvereinbarung wird
Vorwärtssicherheit bereitgestellt. Diese Schlüsselvereinbarung
führt zu einem gemeinsam benutzten Sitzungsschlüssel. Der Rest
der Sitzung wird mit einer symmetrischen Chiffre verschlüsselt. Der
Client wählt aus den vom Server angebotenen Chiffren den
Verschlüsselungsalgorithmus aus. Zusätzlich wird die
Sitzungsintegrität mittels eines kryptographischen
Nachrichtenauthentifizierungscodes (MAC) bereitgestellt.
Schließlich treten der Server und der Client in einen
Authentifizierungsdialog. Der Client versucht sich selbst mittels
Rechner-basierter, asymmetrischer, challenge-response oder Passwort-basierter
Authentifizierung zu authentifizieren.
Unabhängig vom Authentifizierungstyp wird das Konto geprüft, um
sicherzustellen, dass es zugreifbar ist. Ein Konto ist nicht zugreifbar, falls
es gesperrt, in
DenyUsers oder seine Gruppe in in
DenyGroups aufgeführt ist. Die Definition
eines gesperrten Kontos ist systemabhängig. Einige Plattformen haben
ihre eigene Kontendatenbank (z.B. AIX) und andere ändern das
Passwd-Feld (›*LK*‹ auf Solaris und UnixWare, ›*‹
auf HP-UX, enthält ›NOLOGIN‹ auf Tru64, ein
›LOCKED‹ am Anfang auf FreeBSD und ein ›!‹ am
Anfang bei den meisten Linuxen). Falls die Notwendigkeit besteht,
Passwort-basierende Authentifizierung zu deaktivieren, aber weiterhin
asymmetrische Authentifizierung zu erlauben, dann sollte das Passwd-Feld auf
etwas anderes als diese Werte gesetzt werden (z.B. ›NP‹ oder
›*NP*‹).
Falls sich der Client erfolgreich authentifiziert, wird ein Dialog zur
Vorbereitung der Sitzung begonnen. Zu diesem Zeitpunkt kann der Client Dinge
wie die Zuweisung eines Pseudo-TTY, die Weiterleitung von X11-Verbindungen,
die Weiterleitung von TCP-Verbindungen oder die Weiterleitung der Verbindung
des Authentifizierungsvermittlers über den sicheren Kanal erbitten.
Danach fordert der Client entweder eine interaktive Shell oder die
Ausführung eines nichtinteraktiven Befehls, den
sshd mittels der Shell des Benutzers über
die Option
-c ausführt. Beide Seiten
treten dann in den Sitzungsmodus ein. In diesem Modus kann jede Seite zu jeder
Zeit Daten senden, und diese Daten werden dann an die Shell oder den Befehl
auf der Server-Seite und dem Terminal auf der Client-Seite weitergeleitet
(oder kommen von dort).
Wenn sich das Benutzerprogramm beendet und alle weitergeleiteten X11- und
anderen Verbindungen geschlossen wurden, sendet der Server den Exit-Status an
den Client und beide Seiten beenden sich.
Wenn sich ein Benutzer erfolgreich anmeldet, macht
sshd Folgendes:
- Falls die Anmeldung auf einem TTY erfolgt und kein Befehl
angegeben wurde, wird die letzte Anmeldezeit und
/etc/motd ausgegeben (außer dies wird
in der Konfigurationsdatei oder durch
~/.hushlogin verhindert, siehe den Abschnitt
DATEIEN).
- Falls die Anmeldung auf einem TTY erfolgt, wird die
Anmeldezeit aufgezeichnet.
-
/etc/nologin wird
überprüft; falls es existiert, wird der Inhalt ausgegeben
und die Verbindung beendet (außer bei root).
- Die Ausführung wird auf normale Benutzerprivilegien
umgeschaltet.
- Eine grundlegende Umgebung wird eingerichtet.
- Die Datei ~/.ssh/environment,
falls sie existiert, wird eingelesen und Benutzern wird das Ändern
ihrer Umgebung erlaubt. Siehe die Option
PermitUserEnvironment in
sshd_config(5).
- Es wird in das Home-Verzeichnis des Benutzers
gewechselt.
- Falls die Datei ~/.ssh/rc
existiert und die Option PermitUserRC in
sshd_config(5) gesetzt ist, wird die Datei
ausgeführt, ansonsten falls
/etc/ssh/sshrc existiert, wird diese
ausgeführt, andernfalls wird xauth(1)
ausgeführt. Den “rc” -Dateien wird das
X11-Authentifizierungsprotokoll und den Cookie auf der Standardeingabe
übergeben. Siehe nachfolgenden Abschnitt
SSHRC.
- Die Shell des Benutzers oder der Befehl wird
ausgeführt. Alle Befehle werden unter der Anmelde-Shell des
Benutzers ausgeführt, wie diese in der Systempasswortdatenbank
festgelegt ist.
Falls die Datei
~/.ssh/rc existiert, führt
sh(1) sie nach dem Einlesen der
Umgebungsvariablen, aber vor dem Starten der Shell des Benutzers oder des
Befehls aus. Sie darf keine Ausgabe auf der Standardausgabe erstellen,
stattdessen muss Stderr verwandt werden. Falls X11-Weiterleitung in Benutzung
ist, wird sie das »proto cookie«-Paar in seiner Standardeingabe
(und
DISPLAY in seiner Umgebung) erhalten.
Das Skript muss
xauth(1) aufrufen, da
sshd Xauth nicht automatisch aufrufen wird, um
X11-Cookies hinzuzufügen.
Der Hauptzweck dieser Datei besteht darin, sämtliche
Initialisierungsroutinen auszuführen, die benötigt werden, um
auf das Home-Verzeichnis des Benutzers zuzugreifen; AFS ist ein besonderes
Beispiel für solch eine Umgebung.
Diese Datei wird wahrscheinlich einigen Initialisierungs-Code enthalten, dem
etwas ähnlicher Art folgt:
if read proto cookie && [ -n "$DISPLAY" ]; then
if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
# X11UseLocalhost=yes
echo add unix:`echo $DISPLAY |
cut -c11-` $proto $cookie
else
# X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | xauth -q -
fi
Falls diese Datei nicht existiert, wird
/etc/ssh/sshrc ausgeführt und falls auch
diese Datei nicht existiert, wird Xauth verwandt, um den Cookie
hinzuzufügen.
AuthorizedKeysFile legt die Dateien fest, die
öffentliche Schlüssel für die asymmetrische
Authentifizierung enthalten. Falls diese Option nicht festgelegt ist, ist die
Vorgabe
~/.ssh/authorized_keys und
~/.ssh/authorized_keys2. Jede Zeile der Datei
enthält einen Schlüssel (leere Zeilen und Zeilen, die mit einem
‘
#’ beginnen, werden als Kommentare
ignoriert). Öffentliche Schlüssel bestehen aus den folgenden,
durch Leerzeichen getrennten Feldern: Optionen, Schlüsseltyp,
Base64-kodierter Schlüssel, Kommentar. Das Optionenfeld ist optional.
Die unterstützten Schlüsseltypen sind:
Das Kommentarfeld wird für nichts verwandt (kann aber für den
Benutzer zur Identifikation des Schlüssels nützlich sein).
Beachten Sie, dass diese Zeilen in diesen Dateien mehrere hundert Byte lang sein
können (aufgrund der Größe der Kodierung des
öffentlichen Schlüssels), bis zu einer Grenze von 8 Kilobyte,
wodurch RSA-Schlüssel bis zu 16 Kilobit erlaubt sind. Normalerweise
geben Sie diese nicht ein, sondern kopieren die Datei
id_dsa.pub,
id_ecdsa.pub,
id_ecdsa_sk.pub,
id_ed25519.pub,
id_ed25519_sk.pub oder
id_rsa.pub und bearbeiten sie.
sshd erzwingt eine minimale
RSA-Schlüssel-Modulogröße von 1024 Bit.
Falls Optionen vorhanden sind, werden diese durch Kommata getrennt angegeben.
Leerzeichen sind nur innerhalb doppelter englischer Anführungszeichen
erlaubt. Die folgenden Optionsangaben werden unterstützt (beachten Sie,
dass bei Optionsschlüsselwörtern die
Groß-/Kleinschreibung egal ist):
- agent-forwarding
- Aktiviert den Weiterleitungsvermittler, der vorher mit der
Option restrict deaktiviert war.
- cert-authority
- Legt fest, dass der aufgeführte Schlüssel
eine Zertifizierungsstelle (CA) ist, der vertraut wird, um signierte
Zertifikate zur Benutzerauthentifizierung zu validieren.
Zertifikate können Zugangsbeschränkungen festlegen,
ähnlich wie bei Schlüsseloptionen. Falls sowohl
Zertifikatsbeschränkungen als auch Schlüsseloptionen
vorhanden sind, wird die restriktivste Vereinigung beider angewandt.
- command="Befehl"
- Legt fest, dass der Befehl immer bei der Verwendung des
Schlüssels zur Authentifizierung ausgeführt wird. Der durch
den Benutzer bereitgestellte Schlüssel (falls vorhanden) wird
ignoriert. Der Befehl wird auf einem PTY ausgeführt, falls der
Client ein PTY anfordert; andernfalls läuft er ohne ein TTY. Falls
ein 8-Bit-fähiger Kanal benötigt wird, darf kein PTY
angefordert werden oder es muss no-pty
festgelegt werden. Um ein englisches Anführungszeichen in dem
Befehl aufzuführen, stellen Sie ihm einen
Rückwärtsschrägstrich voran.
Diese Option kann zur Einschränkung bestimmter öffentlicher
Schlüssel verwandt werden, damit diese nur eine bestimmte Aktion
ausführen. Beispielsweise einen Schlüssel, der nur ferne
Datensicherungen erlaubt, aber nichts sonst. Beachten Sie, dass der Client
TCP- und/oder X11-Weiterleitung festlegen darf, außer dies wird
explizit verboten, z.B. durch Verwendung der Schlüsseloption
restrict.
Der vom Client bereitgestellte Befehl ist in der Umgebungsvariablen
SSH_ORIGINAL_COMMAND verfügbar.
Beachten Sie, dass diese Option für eine Shell-, Befehls- oder
Subsystemausführung gilt. Beachten Sie auch, dass dieser Befehl
durch eine Direktive ForceCommand in
sshd_config(5) ersetzt werden kann.
Falls ein Befehl festgelegt ist und ein Erzwingungsbefehl in einem
für die Authentifizierung verwandten Zertifikat eingebettet ist,
dann wird dieses Zertifikat nur akzeptiert, falls die zwei Befehle
identisch sind.
- environment="NAME=Wert"
- Legt fest, dass die Zeichenkette zu der Umgebung beim
Protokollieren hinzugefügt wird, wenn dieser Schlüssel
verwandt wird. Auf diese Art gesetzte Umgebungsvariablen setzen andere
Vorgabeumgebungswerte außer Kraft. Mehrere Optionen dieser Art sind
erlaubt. Standardmäßig ist die Verarbeitung der Umgebung
deaktiviert und wird mittels der Option
PermitUserEnvironment gesteuert.
- expiry-time="Zeitangabe"
- Legt eine Zeit fest, nach der der Schlüssel nicht
akzeptiert wird. Die Zeit kann als Datum YYYYMMDD[Z] oder eine Zeit
YYYYMMDDHHMM[SS][Z] festgelegt werden. Daten und Zeiten werden in der
Zeitzone des Systems interpretiert, außer es wird ein
»Z«-Zeichen angehängt, dann werden sie in der
UTC-Zeitzone interpretiert.
- from="Musterliste"
- Legt fest, dass zusätzlich zur asymmetrischen
Authentifizierung entweder der kanonische Name des fernen Rechners oder
seine IP-Adresse in der Kommata-getrennten Liste der Muster vorhanden sein
muss. Siehe MUSTER in ssh_config(5)
für weitere Informationen über Muster.
Zusätzlich zum Platzhaltervergleich, der für Rechnernamen oder
Adressen angewandt werden kann, kann ein from
-Abschnitt auf IP-Adressen mit der CIDR address/masklen-Notation passen.
Der Zweck dieser Option besteht darin, optional die Sicherheit zu
erhöhen: asymmetrische Authentifizierung an sich vertraut dem
Netzwerk oder den Name-Servern oder irgendetwas (außer dem
Schlüssel) nicht. Falls allerdings jemand den Schlüssel
klaut, ermöglicht er es dem Eindringling, sich von überall
aus der Welt anzumelden. Diese zusätzliche Option erschwert den
Einsatz eines gestohlenen Schlüssels (es müssten Name-Server
und/oder Router zusätzlich kompromittiert werden, nicht nur der
Schlüssel).
- no-agent-forwarding
- Verbietet die Vermittlerweiterleitung der
Authentifizierung, wenn dieser Schlüssel für die
Authentifizierung verwandt wird.
- no-port-forwarding
- Verbietet die TCP-Weiterleitung, wenn dieser
Schlüssel für die Authentifizierung verwandt wird. Jede
Port-Weiterleitungsanfrage durch den Client wird einen Fehler
zurückliefern. Dies kann beispielsweise bei Verbindungen mit der
Option command verwandt werden.
- no-pty
- Verhindert TTY-Zuweisung (eine Anfrage, ein PTY zuzuweisen,
wird fehlschlagen).
- no-user-rc
- Deaktiviert die Ausführung von
~/.ssh/rc.
- no-X11-forwarding
- Verbietet X11-Weiterleitung, wenn dieser Schlüssel
zur Authentifizierung verwandt wird. Jede X11-Weiterleitungsanfrage vom
Client wird einen Fehler zurückliefern.
- permitlisten="[Rechner:]Port"
- Schränkt ferne Port-Weiterleitung mit der Option
-R von ssh(1)
ein, so dass es nur auf dem festgelegten Rechner (optional) und Port auf
Anfragen wartet. IPv6-Adressen können durch Einschluss der Adresse
in eckige Klammern festgelegt werden. Mehrere Optionen
permitlisten können durch Kommata
getrennt angewandt werden. Rechnernamen können Platzhalter
enthalten, wie dies im Abschnitt MUSTER in
ssh_config(5) beschrieben ist. Eine
Port-Festlegung * passt auf jeden Port.
Beachten Sie, dass die Einstellung
GatewayPorts die Adressen, an denen auf
Anfragen gewartet wird, weiter einschränken kann. Beachten Sie,
dass ssh(1) einen Rechnernamen
“localhost” senden wird, falls kein Rechner, an dem auf
Anfragen gewartet werden soll, bei der Bitte um eine Weiterleitung
angegeben wurde und dass dieser Name anders als die expliziten
Localhost-Adressen “127.0.0.1” und “::1”
behandelt wird.
- permitopen="Rechner:Port"
- Beschränkt Port-Weiterleitungen mit der Option
-L von ssh(1),
so dass nur Verbindungen zu dem festgelegten Rechner und Port
möglich sind. IPv6-Adressen können durch Einschluss der
Adresse in eckige Klammern festgelegt werden. Mehrere Optionen
permitopen können durch Kommata
getrennt angewandt werden. Es erfolgt bei den festgelegten Rechnernamen
kein Mustervergleich und Namensauflösung, sie müssen
wortwörtliche Rechnernamen und/oder Adressen sein. Eine
Port-Festlegung * passt auf jeden Port.
- port-forwarding
- Aktiviert Port-Weiterleitung, die vorher mit der Option
restrict deaktiviert wurde.
- principals="Prinzipale"
- Legt auf einer cert-authority
-Zeile die erlaubten Prinzipale für die
Zertifikatsauthentifizierung als Kommata-getrennte Liste fest. Mindestens
ein Name aus der Liste muss in der Zertifikatsliste der Prinzipale
erscheinen, damit das Zertifikat akzeptiert wird. Diese Option wird
für Schlüssel, die nicht mit der Option
cert-authority als vertrauenswürdige
Zertifikatsignierer markiert sind, ignoriert.
- pty
- Erlaubt TTY-Zuweisung, die vorher mit der Option
restrict deaktiviert wurde.
- no-touch-required
- Erfordert keinen Nachweis der Anwesenheit des Benutzers
für Signaturen, die mittels dieses Schlüssels erfolgten.
Diese Option ergibt nur für die FIDO-Authenticator-Algorithmen
ecdsa-sk und
ed25519-sk Sinn.
- verify-required
- Verlangt, dass mit diesem Schlüssel erstellte
Signaturen beglaubigen, dass sie vom Benutzer bestätigt wurden,
z.B. über eine PIN. Diese Option ergibt nur für die
FIDO-Authenticator-Algorithmen ecdsa-sk und
ed25519-sk Sinn.
- restrict
- Aktiviert alle Beschränkungen, d.h. deaktiviert die
Weiterleitung vom Port, Vermittler und X11, sowie deaktiviert die
PTY-Zuweisung und die Ausführung von
~/.ssh/rc. Falls zukünftig weitere
Beschränkungsfähigkeiten zu den authorized_keys-Dateien
hinzugefügt werden, werden sie in diese Menge aufgenommen.
- tunnel="n"
- Erzwingt ein tun(4)
-Gerät auf dem Server. Ohne diese Option wird das nächste
verfügbare Gerät verwandt, falls der Client einen Tunnel
anfordert.
- user-rc
- Aktiviert die Ausführung von
~/.ssh/rc, die vorher durch die Option
restrict deaktiviert war.
- X11-forwarding
- Erlaubt X11-Weiterleitung, die vorher durch die Option
restrict deaktiviert war.
Ein Beispiel für eine authorized_keys-Datei:
# Kommentare dürfen am Zeilenanfang anfangen. Leere Zeilen sind erlaubt.
# Einfacher Schlüssel, keine Einschränkung
ssh-rsa …
# Befehl erzwingen, deaktiviert PTY und sämtliche Weiterleitung
restrict,command="dump /home" ssh-rsa …
# »ssh -L«-Weiterleitungsziele beschränken
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-rsa …
# Auf Anfrage wartende »ssh -R«-Weiterleitungen beschränken
permitlisten="localhost:8080",permitlisten="[::1]:22000" ssh-rsa …
# Konfiguration für lokale Tunnel-Weiterleitung
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa …
# Außerkraftsetzung der Beschränkung, um PTY-Zuweisungen zu erlauben
restrict,pty,command="nethack" ssh-rsa …
# FIDO-Schlüssel erlauben, ohne Berührung zu erzwingen
no-touch-required [email protected] …
# Benutzer-Überprüfung (z.B. PIN oder Biometrie) für FIDO-Schlüssel verlangen
verify-required [email protected] …
# CA-Schlüssel vertrauen, berühungsloses FIDO erlauben, falls im Zertifikat erbeten
cert-authority,no-touch-required,principals="user_a" ssh-rsa …
Die Dateien
/etc/ssh/ssh_known_hosts und
~/.ssh/known_hosts enthalten öffentliche
Schlüssel für alle bekannten Rechner. Die globale Datei sollte
durch den Administrator vorbereitet werden (optional) und die benutzerbezogene
Datei wird automatisch verwaltet: immer wenn sich der Benutzer mit einem
unbekannten Rechner verbindet, wird sein Schlüssel zu der
benutzerbezogenen Datei hinzugefügt.
Jede Zeile in diesen Dateien enthält die folgenden Felder: Markierung
(optional), Rechnername, Schlüsseltyp, Base64-kodierter
Schlüssel, Kommentar. Die Felder sind durch Leerzeichen getrennt.
Die Markierung ist optional, falls sie aber vorhanden ist, muss sie entweder
“@cert-authority” sein, um anzuzeigen, dass die Zeile einen
Schlüssel einer Zertifizierungsstelle (CA) ist, oder
“@revoked”, um anzuzeigen, dass der in der Zeile enthaltene
Schlüssel zurückgezogen wurde und niemals akzeptiert werden
darf. Auf einer Schlüsselzeile sollte nur eine Markierung verwandt
werden.
Rechnernamen sind eine durch Kommata getrennte Liste von Mustern
(‘
*’ und
‘
?’ wirken als Platzhalter); jedes
Muster wiederum wird mit dem Rechnernamen verglichen. Wenn
sshd einen Client authentifiziert, wie
beispielsweise bei der Verwendung von
HostbasedAuthentication, wird dies der kanonische
Rechnername sein. Wenn
ssh(1) durch einen Server
authentifiziert wird, wird dies der vom Benutzer angegebene Rechnername sein,
der Wert aus
HostkeyAlias von
ssh(1), falls dieser festgelegt wurde oder der
kanonische Rechnername, falls die Option
CanonicalizeHostname von
ssh(1) verwandt wurde.
Einem Muster kann auch ‘
!’ als Zeichen
für die Verneinung vorangestellt werden: falls der Rechner auf ein
verneintes Muster passt, wird er (durch diese Zeile) überhaupt nicht
akzeptiert, selbst falls er auf ein anderes Muster in dieser Zeile passt. Ein
Rechnername oder eine Adresse kann optional in die Klammern
‘
[’ und
‘
]’ eingeschlossen sein, gefolgt dann
von einem ‘
:’ und einer individuellen
Port-Nummer.
Alternativ können Rechnernamen in einer gehashten Form gespeichert
werden. Diese versteckt die Rechnernamen und -adressen, sollte der Inhalt der
Datei offengelegt werden. Gehashte Rechnernamen beginnen mit dem Zeichen
‘
|’. Auf einer Zeile darf nur ein
einzelner gehashter Rechername auftauchen und die oben beschriebenen
Verneinungs- und Platzhalteroperatoren dürfen nicht angewandt werden.
Der Schlüsseltyp und der Base64-kodierte Schlüssel werden direkt
aus dem Rechnerschlüssel entnommen; sie können beispielsweise
aus
/etc/ssh/ssh_host_rsa_key.pub erhalten
werden. Das optionale Kommentarfeld geht bis zum Zeilenende und wird nicht
verwandt.
Leere Zeilen und Zeilen, die mit ‘
#’
beginnen, werden als Kommentare ignoriert.
Bei der Durchführung von Rechner-Authentifizierung wird die
Authentifizierung akzeptiert, falls auf einer Zeile der geeignete
Schlüssel steht; entweder einer, der genau passt oder, falls der Server
ein Zertifikat für die Authentifizierung präsentiert hat, der
Schlüssel der Zertifizierungsstelle, die das Zertifikat signierte.
Damit einem Schlüssel von einer Zertifizierungsstelle vertraut wird,
muss er die oben beschriebene Markierung “@cert-authority”
verwenden.
Die Datei der bekannten Rechner bietet auch die Möglichkeit,
Schlüssel als widerrufen zu markieren, wenn beispielsweise bekannt ist,
dass der zugehörige private Schlüssel gestohlen wurde.
Widerrufene Schlüssel werden gekennzeichnet, indem die Markierung
“@revoked” am Anfang der Schlüsselzeile aufgenommen wird
und diese werden für die Autorisierung oder als Zertifizierungsstelle
niemals akzeptiert sondern führen zu einer Warnung durch
ssh(1), wenn sie angetroffen werden.
Es ist erlaubt (wird aber nicht empfohlen), mehrere Zeilen oder verschiedene
Rechnerschlüssel für den gleichen Namen zu haben. Dies wird
zwangsläufig passieren, wenn Kurzformen von Rechnernamen von
verschiedenen Domains in der Datei abgelegt werden. Es ist möglich,
dass die Dateien widersprüchliche Informationen enthalten;
Authentifizierung wird akzeptiert, falls gültige Informationen in einer
der Dateien gefunden werden können.
Beachten Sie, dass die Zeilen in diesen Dateien normalerweise Hunderte von
Zeichen lang sind und sie garantiert nicht die Rechnerschlüssel
händisch eingeben wollen. Erstellen Sie sie eher durch ein Skript,
ssh-keyscan(1), oder indem Sie beispielsweise
/etc/ssh/ssh_host_rsa_key.pub verwenden und vorne
Rechnernamen hinzufügen.
ssh-keygen(1)
bietet auch grundlegende automatische Bearbeitung von
~/.ssh/known_hosts an, einschließlich dem
Entfernen von Rechnern, die auf einen Rechnernamen passen und die Umwandlung
aller Rechnernamen in ihre gehashte Darstellung.
Beispiel für eine ssh_known_hosts-Datei:
# Kommentare am Zeilenanfang erlaubt
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234……=
# Ein gehashter Rechnername
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234……=
# Ein widerrufener Schlüssel
@revoked * ssh-rsa AAAAB5W…
# Ein CA-Schlüssel, akzeptiert für jeden Rechner in *.mydomain.com oder *.mydomain.org
@cert-authority *.mydomain.org,*.mydomain.com ssh-rsa AAAAB5W…
- ~/.hushlogin
- Diese Datei wird zum Unterdrücken der Ausgabe der
letzten Anmeldezeit und von /etc/motd, falls
PrintLastLog bzw.
PrintMotd aktiviert wurden, verwandt. Es
unterdrückt nicht die Ausgabe des durch
Banner festgelegten Spruchtextes.
- ~/.rhosts
- Diese Datei wird für Rechner-basierte
Authentifizierung verwandt (siehe ssh(1)
für weitere Informationen). Auf einigen Maschinen muss diese Datei
für alle lesbar sein, falls sich das Home-Verzeichnis des Benutzers
auf einer NFS-Partition befindet, da sshd es
als Root liest. Zusätzlich muss diese Datei dem Benutzer
gehören und darf für keinen anderen eine Schreibberechtigung
enthalten. Die empfohlenen Berechtigungen für die meisten Maschinen
ist lesen/schreiben für den Benutzer und keinen Zugriff für
alle anderen.
- ~/.shosts
- Die Datei wird genau auf die gleiche Art wie
.rhosts verwandt, erlaubt aber
Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu
ermöglichen.
- ~/.ssh/
- Das Verzeichnis ist der Standardort für alle
benutzerspezifischen Konfigurations- und Authentifizierungsinformationen.
Es gibt keine allgemeine Anforderung, sämtliche Informationen in
diesem Verzeichnis geheim zu halten, aber die empfohlenen Berechtigungen
sind Lesen/Schreiben/Ausführen für den Benutzer und kein
Zugriff für andere.
- ~/.ssh/authorized_keys
- Listet die öffentlichen Schlüssel (DSA,
ECDSA, Ed25519, RSA) auf, die für die Anmeldung dieses Benutzers
verwandt werden können. Das Format dieser Datei ist oben
beschrieben. Der Inhalt der Datei ist nicht groß sensitiv, aber die
empfohlenen Berechtigungen sind lesen/schreiben für den Benutzer
und kein Zugriff für alle anderen.
Falls diese Datei, das Verzeichnis ~/.ssh oder
das Home-Verzeichnis des Benutzer für andere Benutzer schreibbar
sind, dann könnte diese Datei durch nicht berechtigte Benutzer
verändert oder ausgetauscht werden. In diesem Fall wird
sshd die Verwendung nicht erlauben,
außer die Option StrictModes wurde auf
“no” gesetzt.
- ~/.ssh/environment
- Diese Datei wird (falls sie existiert) bei der Anmeldung in
die Umgebung gelesen. Sie darf nur leere Zeilen, Kommentarzeilen (die mit
‘
#’ beginnen) und Zuweisungszeilen
der Form Name=Wert enthalten. Die Datei sollte nur für den Benutzer
schreibbar sein; kein anderer Benutzer muss sie lesen können.
Standardmäßig ist die Verarbeitung der Umgebung deaktiviert
und dies wird über die Option
PermitUserEnvironment gesteuert.
- ~/.ssh/known_hosts
- Enthält eine Liste von Rechnerschlüsseln
für alle Rechner, bei denen sich der Benutzer angemeldet hat und
die nicht bereits in der systemweiten Liste der bekannten Rechner
enthalten sind. Das Format dieser Datei ist oben beschrieben. Diese Datei
sollte nur für den Benutzer/root les-/schreibbar sein und muss
nicht für alle lesbar sein.
- ~/.ssh/rc
- Enthält Initialisierungsroutinen, die
ausgeführt werden sollen, bevor das Home-Verzeichnis des Benutzers
zugreifbar wird. In diese Datei sollte nur der Benutzer schreiben
können und sie muss nicht für andere lesbar sein.
- /etc/hosts.allow
-
- /etc/hosts.deny
- Zugriffssteuerungen, die durch tcp-wrappers erzwungen
werden sollen, sind hier definiert. Weitere Details sind in
hosts_access(5) beschrieben.
- /etc/hosts.equiv
- Diese Datei ist für Rechner-basierte
Authentifizierung (siehe ssh(1)). Sie sollte
nur für Root beschreibbar sein.
- /etc/ssh/moduli
- Enthält Diffie-Hellman-Gruppen, die für die
»Diffie-Hellman Group
Exchange«-Schlüsselaustauschmethode verwandt werden. Das
Dateiformat ist in moduli(5) beschrieben.
Falls keine benutzbaren Gruppen in dieser Datei gefunden werden, dann
werden interne Gruppen verwandt.
- /etc/motd
- Siehe motd(5).
- /etc/nologin
- Falls diese Datei existiert, wird
sshd die Anmeldung aller Benutzer
außer Root ablehnen. Der Inhalt der Datei wird allen angezeigt, die
eine Anmeldung versuchen und alle Anmeldungen außer Root werden
abgelehnt. Die Datei sollte für jeden Benutzer lesbar sein.
- /etc/ssh/shosts.equiv
- Die Datei wird genau auf die gleiche Art wie
hosts.equiv verwandt, erlaubt aber
Rechner-basierte Authentifizierung, ohne Anmeldungen mittels Rlogin/Rsh zu
ermöglichen.
- /etc/ssh/ssh_host_ecdsa_key
-
- /etc/ssh/ssh_host_ed25519_key
-
- /etc/ssh/ssh_host_rsa_key
- Diese Dateien enthalten die privaten Anteile der
Rechnerschlüssel. Diese Dateien sollten nur Root gehören,
nur von Root lesbar sein und andere sollten keinen Zugriff darauf haben.
Beachten Sie, dass sshd nicht startet, wenn
auf diese Dateien von Gruppen oder anderen Benutzern zugegriffen werden
kann.
- /etc/ssh/ssh_host_ecdsa_key.pub
-
- /etc/ssh/ssh_host_ed25519_key.pub
-
- /etc/ssh/ssh_host_rsa_key.pub
- Diese Dateien enthalten die öffentlichen Anteile der
Rechnerschlüssel. Diese Dateien sollten von jedem gelesen werden
können, aber nur für Root schreibbar sein. Ihre Inhalte
sollten auf die entsprechenden privaten Teile passen. Diese Dateien werden
nicht wirklich für etwas verwandt, sie sind zum Nutzen der Benutzer
bereitgestellt, so dass ihr Inhalt in die Datei bekannter Rechner kopiert
werden kann. Diese Dateien werden mittels
ssh-keygen(1) erstellt.
- /etc/ssh/ssh_known_hosts
- Systemweite Liste der Schlüssel der bekannten
Rechner. Diese Datei sollte durch den Systemadministrator zusammengestellt
werden, um die Rechner-Schlüssel aller Maschinen in der
Organisation zu enthalten. Das Format der Datei wird oben beschrieben.
Diese Datei sollte nur von Root/dem Eigentümer beschreibbar sein
und von jedem gelesen werden können.
- /etc/ssh/sshd_config
- Enthält Konfigurationsdaten für
sshd. Das Dateiformat und die
Konfigurationsoptionen sind in sshd_config(5)
beschrieben.
- /etc/ssh/sshrc
- Ähnlich wie ~/.ssh/rc
kann sie global zur Angabe maschinen-spezifischer Initialisierung zum
Anmeldezeitpunkt verwandt werden. Diese Datei sollte nur durch Root
beschreibbar und von jedem lesbar sein.
- /run/sshd
- Das von sshd während
der Privilegientrennung in der Vor-Authentifizierungsphase verwandte
chroot(2) -Verzeichnis. Das Verzeichnis
sollte keine Dateien enthalten und muss Root gehören und nicht
für Gruppen oder alle anderen beschreibbar sein.
- /run/sshd.pid
- Enthält die Prozesskennung des
sshd, das auf Verbindungen wartet (falls es
mehrere Daemons gibt, die gleichzeitig auf verschiedenen Ports laufen,
enthält dies die Prozesskennung des zuletzt gestarteten). Der
Inhalt dieser Datei ist nicht sensitiv; sie kann für alle lesbar
sein.
scp(1),
sftp(1),
ssh(1),
ssh-add(1),
ssh-agent(1),
ssh-keygen(1),
ssh-keyscan(1),
chroot(2),
hosts_access(5),
moduli(5),
sshd_config(5),
inetd(8),
sftp-server(8)
OpenSSH ist eine Ableitung der ursprünglichen und freien
SSH-1.2.12-Veröffentlichung durch
Tatu
Ylonen.
Aaron Campbell, Bob Beck, Markus
Friedl, Niels Provos, Theo de Raadt und
Dug
Song entfernten viele Fehler, fügten neue
Funktionalitäten wieder hinzu und erstellten OpenSSH.
Markus Friedl steuerte die
Unterstützung für SSH-Protokollversion 1.5 und 2.0 bei.
Niels Provos und
Markus Friedl steuerten die
Unterstützung für die Privilegientrennung bei.
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann
<
[email protected]> erstellt.
Diese Übersetzung ist Freie Dokumentation; lesen Sie die
GNU
General Public License Version 3 oder neuer bezüglich der
Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.
Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken
Sie bitte eine E-Mail an die Mailingliste der Übersetzer:
[email protected]