Skip to main content

Alles über den Linux / Unix-Befehl: sshd

Linux Tip | How To Use SSH Remote Login (April 2025)

Linux Tip | How To Use SSH Remote Login (April 2025)
Anonim

Name

sshd - OpenSSH SSH-Daemon

Zusammenfassung

sshd -deiqtD46 -b Bits -f Konfigurationsdatei -G login_grace_time -h host_key_file -k key_gen_time -O Möglichkeit -p Hafen -u len

Beschreibung

sshd (SSH-Daemon) ist das Daemon-Programm für ssh (1). Zusammen ersetzen diese Programme rlogin und rshund bieten eine sichere, verschlüsselte Kommunikation zwischen zwei nicht vertrauenswürdigen Hosts über ein unsicheres Netzwerk. Die Programme sollen so einfach zu installieren und zu verwenden sein wie möglich.

sshd ist der Daemon, der auf Verbindungen von Clients wartet. Es wird normalerweise beim Booten von / etc / rc aus gestartet. Es gibt für jede eingehende Verbindung einen neuen Daemon auf. Die verzweigten Daemons übernehmen Schlüsselaustausch, Verschlüsselung, Authentifizierung, Befehlsausführung und Datenaustausch. Diese Implementierung vonsshd unterstützt beide SSH-Protokollversionen 1 und 2 gleichzeitig.

SSH-Protokollversion 1

Jeder Host verfügt über einen hostspezifischen RSA-Schlüssel (normalerweise 1024 Bit), mit dem der Host identifiziert wird. Wenn der Dämon gestartet wird, generiert er außerdem einen Server-RSA-Schlüssel (normalerweise 768 Bit). Dieser Schlüssel wird normalerweise jede Stunde neu generiert, wenn er verwendet wurde, und wird niemals auf der Festplatte gespeichert.

Immer wenn ein Client eine Verbindung herstellt, antwortet der Dämon mit seinen öffentlichen Host- und Serverschlüsseln. Der Client vergleicht den RSA-Hostschlüssel mit seiner eigenen Datenbank, um sicherzustellen, dass er nicht geändert wurde. Der Client generiert dann eine 256-Bit-Zufallszahl. Er verschlüsselt diese Zufallszahl sowohl mit dem Host-Schlüssel als auch dem Server-Schlüssel und sendet die verschlüsselte Nummer an den Server. Beide Seiten verwenden dann diese Zufallszahl als Sitzungsschlüssel, mit dem alle weiteren Kommunikationen in der Sitzung verschlüsselt werden. Der Rest der Sitzung wird mit einer herkömmlichen Chiffre, derzeit Blowfish oder 3DES, verschlüsselt, wobei standardmäßig 3DES verwendet wird. Der Client wählt den zu verwendenden Verschlüsselungsalgorithmus aus den vom Server angebotenen aus.

Als Nächstes geben der Server und der Client ein Authentifizierungsdialogfeld ein. Der Client versucht, sich mithilfe der .rhosts-Authentifizierung, der .rhosts-Authentifizierung in Kombination mit der RSA-Hostauthentifizierung, der RSA-Challenge-Response-Authentifizierung oder der kennwortbasierten Authentifizierung zu authentifizieren.

Die Rhosts-Authentifizierung ist normalerweise deaktiviert, da sie grundsätzlich unsicher ist. Sie kann jedoch in der Serverkonfigurationsdatei aktiviert werden, falls dies gewünscht wird. Die Systemsicherheit wird nur dann verbessertrshdrlogind und rexecd sind deaktiviert (wodurch rlogin und rsh in der Maschine vollständig deaktiviert werden).

SSH-Protokollversion 2

Version 2 funktioniert ähnlich: Jeder Host verfügt über einen hostspezifischen Schlüssel (RSA oder DSA), mit dem der Host identifiziert wird. Beim Starten des Daemons wird jedoch kein Serverschlüssel generiert. Forward-Sicherheit wird durch eine Diffie-Hellman-Schlüsselvereinbarung gewährleistet. Diese Schlüsselvereinbarung führt zu einem gemeinsamen Sitzungsschlüssel.

Der Rest der Sitzung wird mit einer symmetrischen Verschlüsselung verschlüsselt, derzeit 128 Bit AES, Blowfish, 3DES, CAST128, Arcfour, 192 Bit AES oder 256 Bit AES. Der Client wählt den zu verwendenden Verschlüsselungsalgorithmus aus den vom Server angebotenen aus. Darüber hinaus wird die Sitzungsintegrität durch einen kryptographischen Nachrichtenauthentifizierungscode (hmac-sha1 oder hmac-md5) bereitgestellt.

Protokollversion 2 bietet eine auf öffentlichen Schlüsseln basierende Authentifizierungsmethode für Benutzer (PubkeyAuthentication) oder Clienthost (HostbasedAuthentication), eine herkömmliche Kennwortauthentifizierung und auf Challenge-Response basierende Methoden.

Befehlsausführung und Datenweiterleitung

Wenn der Client sich erfolgreich authentifiziert hat, wird ein Dialog zur Vorbereitung der Sitzung angezeigt. Zu diesem Zeitpunkt kann der Client unter anderem anfordern, eine Pseudo-tty zuzuordnen, X11-Verbindungen weiterzuleiten, TCP / IP-Verbindungen weiterzuleiten oder die Authentifizierungsagent-Verbindung über den sicheren Kanal weiterzuleiten.

Schließlich fordert der Client entweder eine Shell oder die Ausführung eines Befehls an. Die Seiten wechseln dann in den Sitzungsmodus. In diesem Modus können beide Seiten jederzeit Daten senden, und diese Daten werden an / von der Shell oder dem Befehl auf der Serverseite und dem Benutzerterminal auf der Clientseite weitergeleitet.

Wenn das Benutzerprogramm beendet ist und alle weitergeleiteten X11- und anderen Verbindungen geschlossen wurden, sendet der Server den Befehlsexitstatus an den Client und beide Seiten werden beendet.

sshd kann mit Befehlszeilenoptionen oder einer Konfigurationsdatei konfiguriert werden. Befehlszeilenoptionen überschreiben die in der Konfigurationsdatei angegebenen Werte.

sshd liest seine Konfigurationsdatei erneut aus, wenn ein Auflegen-Signal empfangen wird,SEUFZEND indem er sich mit dem Namen ausführt, als wurde er gestartet, d. h. / usr / sbin / sshd

Die Optionen sind wie folgt:

-b Bits

Gibt die Anzahl der Bits im Serverschlüssel der Ephemeral Protocol-Version 1 an (Standardwert 768).

-d

Debug-Modus. Der Server sendet eine ausführliche Debug-Ausgabe an das Systemprotokoll und stellt sich nicht in den Hintergrund. Der Server funktioniert auch nicht und verarbeitet nur eine Verbindung. Diese Option ist nur zum Debuggen für den Server vorgesehen. Mehrere -d-Optionen erhöhen den Debugging-Level. Maximum ist 3.

-e

Wenn diese Option angegeben ist,sshd sendet die Ausgabe an den Standardfehler anstelle des Systemprotokolls.

-f Konfigurationsdatei

Gibt den Namen der Konfigurationsdatei an. Der Standard ist / etc / ssh / sshd_configsshdstartet nicht, wenn keine Konfigurationsdatei vorhanden ist.

-G login_grace_time

Gibt die Kulanzzeit für die Authentifizierung der Clients an (Standard: 120 Sekunden). Wenn der Client den Benutzer innerhalb dieser vielen Sekunden nicht authentifiziert, trennt der Server die Verbindung und wird beendet.Ein Wert von Null zeigt kein Limit an.

-h host_key_file

Gibt eine Datei an, aus der ein Hostschlüssel gelesen wird. Diese Option muss angegeben werden, wennsshd wird nicht als root ausgeführt (da die normalen Hostschlüsseldateien normalerweise nur von root gelesen werden können). Der Standard ist / etc / ssh / ssh_host_key für Protokollversion 1 und / etc / ssh / ssh_host_rsa_key und / etc / ssh / ssh_host_dsa_key für Protokollversion 2. Es ist möglich, mehrere Hostschlüsseldateien für die verschiedenen Protokollversionen und den Hostschlüssel zu haben Algorithmen.

-ich

Gibt das ansshd wird von inetd ausgeführt.sshd Normalerweise wird inetd nicht ausgeführt, da der Serverschlüssel generiert werden muss, bevor er auf den Client reagieren kann. Dies kann einige Sekunden dauern. Die Clients müssten zu lange warten, wenn der Schlüssel jedes Mal neu generiert würde. Bei kleinen Schlüsselgrößen (z. B. 512) jedoch verwendensshd von inetd kann machbar sein.

-k key_gen_time

Gibt an, wie oft der Serverschlüssel der Version 1 für temporäre Protokolle regeneriert wird (Standardwert 3600 Sekunden oder eine Stunde). Der Grund für die rechtzeitige Regenerierung des Schlüssels besteht häufig darin, dass der Schlüssel nirgendwo gespeichert wird, und nach etwa einer Stunde wird es unmöglich, den Schlüssel zum Entschlüsseln abgefangener Kommunikationen wiederzugewinnen, selbst wenn die Maschine eingeklemmt oder physisch belegt ist. Ein Wert von Null zeigt an, dass der Schlüssel niemals regeneriert wird.

-O Möglichkeit

Kann verwendet werden, um Optionen in dem Format anzugeben, das in der Konfigurationsdatei verwendet wird. Dies ist nützlich, um Optionen anzugeben, für die kein separates Befehlszeilenflag vorhanden ist.

-p Hafen

Gibt den Port an, an dem der Server auf Verbindungen wartet (Standard 22). Mehrere Portoptionen sind zulässig. In der Konfigurationsdatei angegebene Ports werden ignoriert, wenn ein Befehlszeilenport angegeben wird.

-q

Ruhemodus. Es wird nichts an das Systemprotokoll gesendet. Normalerweise werden der Beginn, die Authentifizierung und die Beendigung jeder Verbindung protokolliert.

-t

Testmodus. Überprüfen Sie nur die Gültigkeit der Konfigurationsdatei und die Sicherheit der Schlüssel. Dies ist nützlich zum Aktualisierensshd zuverlässig, da sich Konfigurationsoptionen ändern können.

-u len

Diese Option wird verwendet, um die Größe des Felds in zu bestimmenutmp Struktur, die den Namen des Remote-Hosts enthält. Wenn der aufgelöste Hostname länger ist als len Stattdessen wird der gepunktete Dezimalwert verwendet. Dadurch können Hosts mit sehr langen Hostnamen, die dieses Feld überlaufen, immer noch eindeutig identifiziert werden. Angabe -u0 gibt an, dass nur gepunktete Dezimaladressen in die utmp-Datei eingefügt werden sollten. -u0 wird auch verwendet, um zu verhindernsshd von DNS-Anfragen machen, sofern der Authentifizierungsmechanismus oder die Konfiguration dies nicht erfordern. Authentifizierungsmechanismen, die DNS erfordern, umfassenRhostsAuthenticationRhostsRSAAuthentication HostbasedAuthentication und mit einemfrom = MusterlisteOption in einer Schlüsseldatei. Konfigurationsoptionen, für die DNS erforderlich ist, umfassen die Verwendung eines USER @ HOSTpattern inAllowUsers oderDenyUsers

-D

Wenn diese Option angegeben istsshd wird sich nicht lösen und wird kein Daemon. Dies ermöglicht eine einfache Überwachung vonsshd

-4

Kräftesshd Nur IPv4-Adressen verwenden.

-6

Kräftesshd Nur IPv6-Adressen verwenden.

Konfigurationsdatei

sshd Liest Konfigurationsdaten aus / etc / ssh / sshd_config (oder der mit - angegebenen Datei)f in der Befehlszeile). Das Dateiformat und die Konfigurationsoptionen werden in sshd_config5 beschrieben.

Anmeldeprozess

Wenn sich ein Benutzer erfolgreich anmeldet,sshd macht folgendes:

  1. Wenn sich das Login auf einem tty befindet und kein Befehl angegeben wurde, werden der letzte Login-Zeitpunkt und / etc / motd gedruckt (sofern dies nicht in der Konfigurationsdatei oder durch $ HOME / .hushlogin verhindert wird, siehe Abschnitt Sx FILES).
  2. Wenn sich der Login in einem Feld befindet, wird die Login-Zeit aufgezeichnet.
  3. Überprüft / etc / nologin, ob es existiert, druckt Inhalte und beendet (sofern nicht root).
  4. Änderungen zur Ausführung mit normalen Benutzerberechtigungen.
  5. Stellt eine grundlegende Umgebung ein.
  6. Liest $ HOME / .ssh / environment, wenn es existiert und Benutzer ihre Umgebung ändern dürfen. Siehe diePermitUserEnvironment Option in sshd_config5.
  7. Wechselt zum Heimatverzeichnis des Benutzers.
  8. Wenn $ HOME / .ssh / rc vorhanden ist, wird es ausgeführt. Wenn / etc / ssh / sshrc vorhanden ist, wird es ausgeführt. sonst läuft xauth. Die `` rc'-Dateien erhalten das X11-Authentifizierungsprotokoll und das Cookie als Standardeingabe.
  9. Führt die Shell oder den Befehl des Benutzers aus.

Authorized_Keys-Dateiformat

$ HOME / .ssh / authorised_keys ist die Standarddatei, in der die öffentlichen Schlüssel aufgeführt sind, die für die RSA-Authentifizierung in Protokollversion 1 und für die Authentifizierung mit öffentlichen Schlüsseln (PubkeyAuthentication) in Protokollversion 2 zulässig sind.AuthorizedKeysFile kann verwendet werden, um eine alternative Datei anzugeben.

Jede Zeile der Datei enthält einen Schlüssel (leere Zeilen und Zeilen, die mit einem # beginnen, werden als Kommentar ignoriert). Jeder öffentliche RSA-Schlüssel besteht aus den folgenden Feldern, die durch Leerzeichen getrennt sind: Optionen, Bits, Exponent, Modul und Kommentar. Jeder öffentliche Schlüssel der Protokollversion 2 besteht aus: Optionen, Schlüsseltyp, Base64-codierter Schlüssel und Kommentar. Das Optionsfeld ist optional. Ihr Vorhandensein wird dadurch bestimmt, ob die Zeile mit einer Nummer beginnt oder nicht (das Optionsfeld beginnt niemals mit einer Nummer). Die Bit-, Exponenten-, Modul- und Kommentarfelder geben den RSA-Schlüssel für Protokollversion 1 an. Das Kommentarfeld wird nicht für irgendetwas verwendet (kann jedoch für den Benutzer zum Identifizieren des Schlüssels geeignet sein). Für die Protokollversion 2 lautet der Schlüsseltyp `` ssh-dss '' oder `` ssh-rsa ''.

Beachten Sie, dass die Zeilen in dieser Datei in der Regel mehrere hundert Byte lang sind (aufgrund der Größe der öffentlichen Schlüsselcodierung). Sie möchten sie nicht eingeben. Kopieren Sie stattdessen die Datei identity.pub id_dsa.pub oder id_rsa.pub und bearbeiten Sie sie.

sshd erzwingt eine minimale RSA-Schlüsselmodulgröße für Schlüssel von Protokoll 1 und Protokoll 2 von 768 Bits.

Die Optionen (falls vorhanden) bestehen aus durch Kommas getrennten Optionsangaben. Leerzeichen sind nur in Anführungszeichen zulässig. Die folgenden Optionsspezifikationen werden unterstützt (beachten Sie, dass für Optionsschlüsselwörter die Groß- und Kleinschreibung nicht berücksichtigt wird):

from = Musterliste

Gibt an, dass zusätzlich zur Authentifizierung mit öffentlichen Schlüsseln der kanonische Name des Remote-Hosts in der durch Kommas getrennten Musterliste vorhanden sein muss (`* 'und`?' Dienen als Platzhalter). Die Liste kann auch negierte Muster enthalten, indem sie mit "!" Vorangestellt wird. ; Wenn der kanonische Hostname einem negierten Muster entspricht, wird der Schlüssel nicht akzeptiert. Der Zweck dieser Option besteht darin, die Sicherheit optional zu erhöhen: Die Authentifizierung des öffentlichen Schlüssels an sich vertraut nicht dem Netzwerk, den Nameservern oder irgendetwas (außer dem Schlüssel). Wenn jedoch jemand den Schlüssel stiehlt, ermöglicht der Schlüssel einem Eindringling, sich von überall auf der Welt einzuloggen. Diese zusätzliche Option macht die Verwendung eines gestohlenen Schlüssels schwieriger (Nameserver und / oder -router müssten zusätzlich zum Schlüssel gefährdet werden).

Befehl = Befehl

Gibt an, dass der Befehl ausgeführt wird, wenn dieser Schlüssel zur Authentifizierung verwendet wird. Der vom Benutzer bereitgestellte Befehl (falls vorhanden) wird ignoriert. Der Befehl wird auf einem Pty ausgeführt, wenn der Client ein Pty anfordert. ansonsten läuft es ohne tty. Wenn ein sauberer 8-Bit-Kanal erforderlich ist, muss kein pty angefordert werden oder sollte angegeben werdenkein pty Ein Zitat kann in den Befehl eingefügt werden, indem es mit einem Backslash zitiert wird. Diese Option kann nützlich sein, um bestimmte öffentliche Schlüssel einzuschränken, um nur einen bestimmten Vorgang auszuführen. Ein Beispiel könnte ein Schlüssel sein, der Fernsicherungen zulässt, aber sonst nichts. Beachten Sie, dass der Client die TCP / IP- und / oder X11-Weiterleitung angeben kann, sofern dies nicht ausdrücklich verboten ist. Beachten Sie, dass diese Option für die Ausführung von Shell, Befehl oder Subsystem gilt.

Umgebung = NAME = Wert

Gibt an, dass der String der Umgebung hinzugefügt werden soll, wenn er sich mit diesem Schlüssel anmeldet. Auf diese Weise gesetzte Umgebungsvariablen überschreiben andere Standardumgebungswerte. Mehrere Optionen dieses Typs sind zulässig. Die Umgebungsverarbeitung ist standardmäßig deaktiviert und wird über das Kontrollkästchen gesteuertPermitUserEnvironment Möglichkeit. Diese Option wird automatisch deaktiviert, wennUseLogin aktiviert.

Keine Portweiterleitung

Verbietet die TCP / IP-Weiterleitung, wenn dieser Schlüssel zur Authentifizierung verwendet wird. Alle Portweiterleitungsanforderungen des Clients geben einen Fehler zurück. Dies kann beispielsweise in Verbindung mit der verwendet werdenBefehl Möglichkeit.

no-X11-Weiterleitung

Verbietet die Weiterleitung von X11, wenn dieser Schlüssel zur Authentifizierung verwendet wird. Alle X11-Weiterleitungsanforderungen des Clients geben einen Fehler zurück.

No-Agent-Weiterleitung

Verbietet die Weiterleitung des Authentifizierungsagenten, wenn dieser Schlüssel für die Authentifizierung verwendet wird.

kein pty

Verhindert die Zuweisung von tty (eine Anforderung zum Zuweisen eines pty schlägt fehl).

allowopen = Host: Port

Lokale beschränken`` ssh -L '' Portweiterleitung, sodass nur eine Verbindung zum angegebenen Host und Port hergestellt werden kann. IPv6-Adressen können mit einer alternativen Syntax angegeben werden: Host / Port Mehrere Erlaubnis öffnen Optionen können durch Kommas getrennt angewendet werden. Für die angegebenen Hostnamen wird kein Musterabgleich durchgeführt, es muss sich um literale Domänen oder Adressen handeln.

Beispiele

1024 33 12121 … 312314325 [email protected]

from = "*. niksula.hut.fi,! pc.niksula.hut.fi" 1024 35 23 … 2334 ylo @ niksula

Befehl = "dump / home", kein Port, keine Portweiterleitung 1024 33 23 … 2323 backup.hut.fi

allowopen = "10.2.1.55:80", allowopen = "10.2.1.56:25" 1024 33 23 … 2323

Ssh_Known_Hosts-Dateiformat

Die Dateien / etc / ssh / ssh_known_hosts und $ HOME / .ssh / known_hosts enthalten öffentliche Host-Schlüssel für alle bekannten Hosts. Die globale Datei sollte vom Administrator vorbereitet werden (optional), und die Benutzerdatei wird automatisch verwaltet: Wenn der Benutzer eine Verbindung von einem unbekannten Host her herstellt, wird dessen Schlüssel der Benutzerdatei hinzugefügt.

Jede Zeile in diesen Dateien enthält die folgenden Felder: Hostnamen, Bits, Exponent, Modul und Kommentar. Die Felder sind durch Leerzeichen getrennt.

Hostnamen sind eine durch Kommas getrennte Liste von Mustern ("*" und "?" Fungieren als Platzhalter). Jedes Muster wird wiederum mit dem kanonischen Hostnamen (bei der Authentifizierung eines Clients) oder mit dem vom Benutzer angegebenen Namen (bei der Authentifizierung eines Servers) abgeglichen. Einem Muster kann auch ein "!" Vorangestellt werden. Negation anzeigen: Wenn der Hostname mit einem negierten Muster übereinstimmt, wird er (von dieser Zeile) nicht akzeptiert, auch wenn er mit einem anderen Muster in der Zeile übereinstimmt.

Bits, Exponenten und Module werden direkt vom RSA-Hostschlüssel übernommen. Sie können beispielsweise von /etc/ssh/ssh_host_key.pub erhalten werden. Das optionale Kommentarfeld wird bis zum Ende der Zeile fortgesetzt und wird nicht verwendet.

Zeilen, die mit '#' beginnen, und leere Zeilen werden als Kommentar ignoriert.

Bei der Host-Authentifizierung wird die Authentifizierung akzeptiert, wenn eine übereinstimmende Zeile über den richtigen Schlüssel verfügt. Es ist daher zulässig (aber nicht empfohlen), mehrere Zeilen oder unterschiedliche Host-Schlüssel für denselben Namen zu haben. Dies wird unweigerlich passieren, wenn Kurzformen von Hostnamen aus verschiedenen Domänen in die Datei eingefügt werden. Es ist möglich, dass die Dateien widersprüchliche Informationen enthalten. Die Authentifizierung wird akzeptiert, wenn in beiden Dateien gültige Informationen gefunden werden können.

Beachten Sie, dass die Zeilen in diesen Dateien in der Regel mehrere Hundert Zeichen lang sind und Sie die Host-Schlüssel definitiv nicht manuell eingeben möchten. Generieren Sie sie stattdessen durch ein Skript oder indem Sie /etc/ssh/ssh_host_key.pub verwenden und die Hostnamen an der Vorderseite hinzufügen.

Beispiele

closenet, …, 130.233.208.41 1024 37 159 … 93 closenet.hut.fi cvs.openbsd.org, 199.185.137.3 ssh-rsa AAAA1234 ….. =

Siehe auch

scp (1), sftp (1), ssh (1), ssh-add1, ssh-agent1, ssh-keygen1, login.conf5, module (5), sshd_config5, sftp-server8

T. Ylonen T. Kivinen M. Saarinen T. Rinne S. Lehtinen "SSH-Protokollarchitektur" draft-ietf-secsh-architecture-12.txt Januar 2002 work in progress Material

M. Friedl N. Provos W. A. ​​Simpson "Diffie-Hellman Group Exchange für das SSH-Transportschichtprotokoll" draft-ietf-secsh-dh-group-exchange-02.txt Januar 2002 Material für die Arbeit in Arbeit

Wichtig: Verwenden Sie die Mann Befehl ( % Mann ), um zu sehen, wie ein Befehl auf Ihrem Computer verwendet wird.