Da in Linux, dass SSH essenziell ist, werde ich darauf sehr genau eingehen, bis auf Key Schlüssel, damit ist eine SSH Anmeldung möglich ohne Passwort abfrage. Wir werden uns dies, unter UBUNTU 2004 LTS ansehen. Egal welche Distribution wir benutzen UBUNTU/DEBAIN, Arch Linux, Red HAT usw., dass vorgehen ist dermaßen ähnlich, dass man gleich Behandeln kann. Genau dies macht Linux aus, von der ferne darauf zuzugreifen, als wäre man Vorort.
Wen jemand, in der IT arbeitet, wird auch viel mit SSH zu tun bekommen, da die NAS, Firewall, Switches usw. ebenso auf Linux passiert und das Protokoll SSH zugutekommt. Man ist zwar etwas mehr eingeschränkt, wie wen man eine Nativ Linux benutzt, aber dies ist so gewollt, damit man die Appliance nicht zerstört.


Inhaltsverzeichnis

  1. Erklärung
    1. Zugriff mit OpenSSH
  2. Installation
  3. Konfiguration
    1. Port
    2. AddressFamily
    3. ListenAddress
    4. RekeyLimit
      1. TIME FORMATS
    5. SyslogFacility
    6. LogLevel
    7. LoginGraceTime
    8. PermitRootLogin
    9. PasswordAuthentication
    10. PermitEmptyPasswords
    11. KerberosAuthentication
    12. KerberosOrLocalPasswd
    13. KerberosTicketCleanup
    14. KerberosGetAFSToken
    15. GSSAPIAuthentication
    16. GSSAPICleanupCredentials
    17. GSSAPIStrictAcceptorCheck
    18. GSSAPIKeyExchange
    19. UsePAM
    20. AllowAgentForwarding
    21. AllowTcpForwarding
    22. AllowTcpForwarding
    23. X11Forwarding
    24. X11DisplayOffset
    25. X11UseLocalhost
    26. PermitTTY
    27. PrintMotd
    28. PrintLastLog
    29. TCPKeepAlive
    30. UseLogin
    31. PermitUserEnvironment
    32. Compression
    33. ClientAliveInterval
    34. ClientAliveCountMax
    35. UseDNS
    36. PidFile
    37. MaxStartups
    38. PermitTunnel
    39. ChrootDirectory
    40. VersionAddendum
    41. Banner
    42. AcceptEnv
    43. Subsystem
    44. PasswordAuthentication
  4. System

Erklärung

Das SSH Secure Shell, es stellt eine Kommandozeile zur Verfügung, womit man ein Linux System von der Ferne aus steuern kann. Es funktioniert, wie ein Client Server Model und das Paket heißt OpenSSH. Von einem Linux aus benutzt man einfach einen Terminal, dass jedes Linux automatisch mit installiert hat, dasselbe ist bei einem MacOS, da es ein Linux basierendes Betriebssystem ist. Bei Windows ist es etwas anderes, da gibt es, dass beliebte Programm “Putty“, was aber der Windows 10 1803 oder Server 2019 nicht mehr zwingend benötigt wird, das Paket OpenSSH automatisch von Microsoft mit installiert, seit diesen Versionen. Man öffnet einfach CMD oder PowerShell.

Zugriff mit OpenSSH

ssh username@servername (DNS oder IP-Adresse)

Beispiel:

ssh test@192.168.0.1
ArgumenteBeschreibung
-1Verwenden Sie nur Protokollversion 1
-2Verwenden Sie nur Protokollversion 2
-4Verwenden Sie nur IPv4-Adressen
-6Verwenden Sie nur IPv6-Adressen
-AAktivieren Sie die Weiterleitung der Authentifizierungsagentenverbindung.
-aDeaktivieren Sie die Weiterleitung der Authentifizierungsagentenverbindung.
-CVerwenden Sie die Datenkomprimierung.
-c cipher_specWählt die Verschlüsselungsspezifikation zum Verschlüsseln der Sitzung aus.
-D [bind_address:]portDynamische Portweiterleitung auf Anwendungsebene.Dadurch wird ein Socket zugewiesen, um den Port auf der lokalen Seite abzuhören. Wenn eine Verbindung zu diesem Port hergestellt wird, wird die Verbindung über den sicheren Kanal weitergeleitet, und das Anwendungsprotokoll wird dann verwendet, um zu bestimmen, wo vom Remotecomputer aus eine Verbindung hergestellt werden soll.
-E log_fileFügen Sie anstelle des Standardfehlers Debug-Protokolle an log_file an.
-F configfileGibt eine Konfigurationsdatei pro Benutzer an.Der Standardwert für die Benutzerkonfigurationsdatei ist ~ /.ssh/config.
-gErmöglicht Remote-Hosts die Verbindung zu lokal weitergeleiteten Ports.
-i identity_fileEine Datei, aus der der Identitätsschlüssel (privater Schlüssel)für die Authentifizierung mit öffentlichem Schlüssel gelesen wird.
-J [user@]host[:port]Stellen Sie eine Verbindung zum Zielhost her,indem Sie zuerst eine SSH-Verbindung zum Jump-Host (/iam/jump-host) herstellen und dann von dort aus eine TCP-Weiterleitung zum endgültigen Ziel einrichten.
-l login_nameGibt den Benutzer an, der sich auf dem Remotecomputer anmelden soll.
-p portPort, zu dem eine Verbindung auf dem Remote-Host hergestellt werden soll.
-qRuhemodus
-VZeigen Sie die Versionsnummer an.
-vAusführlicher Modus.
-XAktiviert die X11-Weiterleitung.
Wichtigste Argumente

Danach noch geben wir, dass entsprechende Kennwort ein und wir haben Zugriff auf den entsprechenden Server.


Installation

Sollte dieses Paket nicht installiert sein, kann man es einfach nachziehen.

sudo apt install -y openssh-server

Konfiguration

Bevor wir etwas ändern werden wir ein Backup der Konfigurationsdatei anlegen.

sudo cp /etc/ssh/sshd_config /etc/ssh/bck_sshd_config

Wir werden nun die Konfigurationsdatei bearbeiten und SSH Zugriff personalisieren.

cd /etc/ssh/

Bevor wir etwas ändern, macht, es Sinn ein Backup der Datei zu erstellen und zum Verständnis, alle auskommentierte Werte, sind Standard Werte. Sobald wir einen Wert, auskommentieren, wird automatisch der Standard Wert benutzt. Sehen wir uns nun die Datei an.

sudo nano sshd_config

Wir werden uns, die einzelnen Argumente an, um den SSH-Zugriff zu personalisieren.

Port

Gibt die Postnummer an, die sshd abhört. Der Standardwert ist 22. Mehrere Optionen dieses Typs sind zulässig. Siehe auch ListenAddress.

AddressFamily

Gibt an, welche Adressfamilie beim Herstellen einer Verbindung verwendet werden soll. Gültige Argumente sind any (Standard), inet (nur IPv4 verwenden) oder inet6 (nur IPv6 verwenden).

ListenAddress

Geben Sie mit ListenAddress, in jeder neuen Zeile eine IP-Adresse an, die Abgehört wird (mehrere ListenAddress-Optionen sind zulässig, ebenso IPv4 und IPv6).

Zulässige Formate:

  • ListenAddress Hostname | Adresse [domain]
  • ListenAddress Hostname: port [domain]
  • ListenAddress IPv4_address: port [domain]
  • ListenAddress [Hostname | Adresse]: Port [domain]

RekeyLimit

Gibt die maximale Datenmenge an, die übertragen werden kann, bevor der Sitzungsschlüssel neu ausgehandelt wird, optional gefolgt von einer maximalen Zeitspanne, die vergehen kann, bevor der Sitzungsschlüssel neu ausgehandelt wird. Das erste Argument wird in Bytes angegeben und kann das Suffix “K”, “M” oder “G” haben, um Kilobyte, Megabyte bzw. Gigabyte anzugeben. Der Standardwert liegt je nach Verschlüsselung zwischen “1G” und “4G”. Der optionale zweite Wert wird in Sekunden angegeben und kann alle im Abschnitt TIME FORMATS von dokumentierten Einheiten verwenden. Der Standardwert für RekeyLimit ist default none. Dies bedeutet, dass eine erneute Eingabe durchgeführt wird, nachdem die Standarddatenmenge der Verschlüsselung gesendet oder empfangen wurde und keine zeitbasierte erneute Eingabe erfolgt.

TIME FORMATS

sshd Befehlszeilenargumente und Konfigurationsdateioptionen, die die Zeit angeben, können in einer Folge der folgenden Form ausgedrückt werden: time [Qualifier], wobei time ein positiver ganzzahliger Wert ist und qualifier einer der folgenden Werte ist:

VariableBeschreibung
{none}Sekunde(n)
s|SSekunde(n)
m|MMinute(n)
h|HStunde(n)
d|DTag(e)
w|WWoche(n)

SyslogFacility

Gibt den Einrichtungscode an, der beim Protokollieren von Nachrichten von SSH verwendet wird. Die möglichen Werte sind: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. Der Standardwert ist USER.

LogLevel

Gibt die Ausführlichkeitsstufe an, die beim Protokollieren von Nachrichten von SSH verwendet wird. Die möglichen Werte sind: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2 und DEBUG3.

Der Standardwert ist INFO. DEBUG und DEBUG1 sind gleichwertig. DEBUG2 und DEBUG3 geben jeweils höhere Ebenen der ausführlichen Ausgabe an.

LoginGraceTime

Die Zeit, nach der der Server die Verbindung trennt, wenn sich der Benutzer nicht erfolgreich angemeldet hat.

PermitRootLogin

Gibt an, ob sich Root mit SSH anmelden kann. Das Argument muss yes, prohibit-password, forced-commands-only oder no sein. Die Standardeinstellung ist “prohibit-password”.
Wenn diese Option auf “prohibit-password” (oder den veralteten Alias “without-password”) eingestellt ist, sind die Kennwort- und Tastatur-interaktive Authentifizierung für Root deaktiviert.
Wenn diese Option auf “forced-commands-only” eingestellt ist, ist die Root-Anmeldung mit Authentifizierung mit öffentlichem Schlüssel zulässig, jedoch nur, wenn die Befehlsoption angegeben wurde (was nützlich sein kann, um Remote-Backups zu erstellen, auch wenn die Root-Anmeldung normalerweise nicht zulässig ist). Alle anderen Authentifizierungsmethoden sind für Root deaktiviert.
Wenn diese Option auf no gesetzt ist, darf sich Root nicht anmelden.

PasswordAuthentication

Gibt an, ob die Kennwortauthentifizierung zulässig ist. Der Standardwert ist yes.

PermitEmptyPasswords

Wenn die Kennwortauthentifizierung zulässig ist, wird angegeben, ob der Server die Anmeldung bei Konten mit leeren Kennwortzeichenfolgen zulässt. Der Standardwert ist no.

KerberosAuthentication

Gibt an, ob das vom Benutzer für PasswordAuthentication angegebene Kennwort über das Kerberos-KDC überprüft wird. Um diese Option verwenden zu können, benötigt der Server ein Kerberos-Servtab, mit dem die Identität des KDC überprüft werden kann. Der Standardwert ist no.

KerberosOrLocalPasswd

Wenn die Kennwortauthentifizierung über Kerberos fehlschlägt, wird das Kennwort über einen zusätzlichen lokalen Mechanismus wie /etc/passwd überprüft. Der Standardwert ist yes.

KerberosTicketCleanup

Gibt an, ob die Ticket-Cache-Datei des Benutzers beim Abmelden automatisch zerstört werden soll. Der Standardwert ist yes.

KerberosGetAFSToken

Wenn AFS aktiv ist und der Benutzer über ein Kerberos 5 TGT verfügt, versuchen Sie, ein AFS-Token abzurufen, bevor Sie auf das Basisverzeichnis des Benutzers zugreifen. Der Standardwert ist no.

GSSAPIAuthentication

Gibt an, ob eine Benutzerauthentifizierung basierend auf GSSAPI zulässig ist. Der Standardwert ist no.

GSSAPICleanupCredentials

Gibt an, ob der Cache für Anmeldeinformationen des Benutzers beim Abmelden automatisch zerstört werden soll. Der Standardwert ist yes.

GSSAPIStrictAcceptorCheck

Legt fest, ob die Identität des GSSAPI-Akzeptors, gegen den sich ein Client authentifiziert, streng ist. Wenn diese Option auf “yes” gesetzt ist, muss sich der Client beim aktuellen Hostnamen beim Host Dienst authentifizieren. Wenn no festgelegt ist, kann sich der Client bei jedem im Standardspeicher des Computers gespeicherten Serviceschlüssel authentifizieren. Diese Funktion unterstützt den Betrieb auf Multi-Homed-Maschinen. Der Standardwert ist yes.

GSSAPIKeyExchange

Gibt an, ob ein auf GSSAPI basierender Schlüsselaustausch zulässig ist. GSSAPI-Schlüsselaustausch verlässt sich nicht auf SSH-Schlüssel, um die Hostidentität zu überprüfen. Der Standardwert ist no.

UsePAM

Aktiviert die Schnittstelle des Pluggable Authentication Module. Wenn ja, wird dies Aktivieren Sie die PAM-Authentifizierung mit ChallengeResponseAuthentication und PasswordAuthentication zusätzlich zur Verarbeitung des PAM-Kontos und des Sitzungsmoduls für alle Authentifizierungstypen.
Da die PAM-Challenge-Response-Authentifizierung normalerweise eine gleichwertige Rolle spielt. Bei der Kennwortauthentifizierung sollten Sie entweder die Kennwortauthentifizierung oder deaktivieren ChallengeResponseAuthentication.
Wenn UsePAM aktiviert ist, können Sie sshd (8) nicht als Nicht-Root-Benutzer ausführen. Der Standard ist no.

AllowAgentForwarding

Gibt an, ob die Weiterleitung von SSH-Agent zulässig ist. Der Standardwert ist Ja. Beachten Sie, dass das Deaktivieren der Agentenweiterleitung die Sicherheit nur verbessert, wenn Benutzern auch der Shell-Zugriff verweigert wird, da sie jederzeit ihre eigenen Weiterleitungen installieren können.

AllowTcpForwarding

Gibt an, ob die TCP-Weiterleitung zulässig ist. Die verfügbaren Optionen sind Ja (Standardeinstellung) oder alle, um die TCP-Weiterleitung zuzulassen, Nein, um die gesamte TCP-Weiterleitung zu verhindern, Lokal, um nur die lokale (aus Sicht von SSH) Weiterleitung zuzulassen, oder Remote, um nur die Fernweiterleitung zuzulassen. Beachten Sie, dass das Deaktivieren der TCP-Weiterleitung die Sicherheit nur verbessert, wenn Benutzern auch der Shell-Zugriff verweigert wird, da sie jederzeit ihre eigenen Weiterleitungen installieren können.

GatewayPorts

Gibt an, ob Remote-Hosts eine Verbindung zu für den Client weitergeleiteten Ports herstellen dürfen. Standardmäßig bindet sshd Remote-Port-Weiterleitungen an die Loopback-Adresse. Dies verhindert, dass andere Remote-Hosts eine Verbindung zu weitergeleiteten Ports herstellen. Mit GatewayPorts kann angegeben werden, dass sshd die Weiterleitung von Remote-Port-Weiterleitungen an Non-Loopback-Adressen ermöglichen soll, damit andere Hosts eine Verbindung herstellen können. Das Argument kann Nein sein, um zu erzwingen, dass Remote-Port-Weiterleitungen nur für den lokalen Host verfügbar sind, Ja, um zu erzwingen, dass Remote-Port-Weiterleitungen an die Wildcat-Adresse gebunden werden, oder Clients, die angegeben werden, damit der Client die Adresse auswählen kann, an die die Weiterleitung gebunden ist. Der Standardwert ist no.

X11Forwarding

Gibt an, ob die X11-Weiterleitung zulässig ist. Das Argument muss ja oder nein sein. Der Standardwert ist no.
Wenn die X11-Weiterleitung aktiviert ist, kann es zu einer zusätzlichen Gefährdung des Servers und der Client-Anzeigen kommen, wenn die Proxy-Anzeige sshd so konfiguriert ist, dass die Wildcat-Adresse abgehört wird (siehe X11UseLocalhost), obwohl dies nicht die Standardeinstellung ist. Darüber hinaus erfolgt die Überprüfung und Ersetzung der Authentifizierungsspoofing- und Authentifizierungsdaten auf der Clientseite. Das Sicherheitsrisiko bei der Verwendung der X11-Weiterleitung besteht darin, dass der X11-Anzeigeserver des Clients möglicherweise Angriffen ausgesetzt ist, wenn der SSH-Client die Weiterleitung anfordert (siehe die Warnungen für ForwardX11 in ssh_config). Ein Systemadministrator kann eine Haltung einnehmen, in der er Clients schützen möchte, die sich Angriffen aussetzen können, indem er unabsichtlich eine X11-Weiterleitung anfordert, was eine Nichteinstellung rechtfertigen kann.
Beachten Sie, dass das Deaktivieren der X11-Weiterleitung Benutzer nicht daran hindert, X11-Verkehr weiterzuleiten, da Benutzer jederzeit ihre eigenen Weiterleitungen installieren können.

X11DisplayOffset

Gibt die erste verfügbare Anzeigenummer für die X11-Weiterleitung von sshd an. Dies verhindert, dass sshd echte X11-Server stört. Der Standardwert ist 10.

X11UseLocalhost

Gibt an, ob sshd den X11-Weiterleitungsserver an die Loopback-Adresse oder an die Wildcat-Adresse binden soll. Standardmäßig bindet sshd den Weiterleitungsserver an die Loopback-Adresse und setzt den Hostnamen-Teil der Umgebungsvariablen DISPLAY auf localhost. Dies verhindert, dass Remote-Hosts eine Verbindung zur Proxy-Anzeige herstellen. Einige ältere X11-Clients funktionieren jedoch möglicherweise nicht mit dieser Konfiguration. X11UseLocalhost kann auf no gesetzt werden, um anzugeben, dass der Weiterleitungsserver an die Wildcat-Adresse gebunden werden soll. Das Argument muss ja oder nein sein. Der Standardwert ist yes.

PermitTTY

Gibt an, ob die Zuweisung von pty zulässig ist. Der Standardwert ist yes.

PrintMotd

Gibt an, ob sshd /etc/motd drucken soll, wenn sich ein Benutzer interaktiv anmeldet. (Auf einigen Systemen wird es auch von der Shell, /etc/profile oder einem gleichwertigen System gedruckt). Der Standardwert ist yes.

PrintLastLog

Gibt an, ob sshd das Datum und die Uhrzeit der letzten Benutzeranmeldung drucken soll, wenn sich ein Benutzer interaktiv anmeldet. Der Standardwert ist yes.

TCPKeepAlive

Gibt an, ob das System TCP-Keepalive-Nachrichten an die andere Seite senden soll. Wenn sie gesendet werden, wird der Tod der Verbindung oder der Absturz einer der Maschinen ordnungsgemäß bemerkt. Dies bedeutet jedoch, dass Verbindungen unterbrochen werden, wenn die Route vorübergehend unterbrochen wird, und einige Leute finden es ärgerlich. Wenn andererseits keine TCP-Keepalives gesendet werden, können Sitzungen auf unbestimmte Zeit auf dem Server hängen bleiben, wodurch “Geister” -Benutzer zurückbleiben und Serverressourcen verbraucht werden.
Der Standardwert ist yes (zum Senden von TCP-Keepalive-Nachrichten), und der Server wird feststellen, ob das Netzwerk ausfällt oder der Client-Host abstürzt. Dies vermeidet unendlich hängende Sitzungen.
Um TCP-Keepalive-Nachrichten zu deaktivieren, sollte der Wert auf no gesetzt werden.

UseLogin

Wenn die Option UseLogin aktiviert ist, wechselt der OpenSSH-Server (sshd) nicht zur UID des Benutzers, der sich anmeldet, sondern verlässt sich stattdessen auf Login, um den Job auszuführen. Wenn der Benutzer jedoch einen Befehl für die Remote-Ausführung angibt, kann die Anmeldung nicht verwendet werden und sshd kann die richtige Benutzer-ID nicht festlegen. Das Ergebnis ist, dass der Befehl mit demselben Privileg wie sshd ausgeführt wird (normalerweise mit Root) und es Benutzern grundsätzlich ermöglicht, Root-Privilegien zu erhalten.

PermitUserEnvironment

Gibt an, ob die Optionen ~ /.ssh/environment und environment = in ~/.ssh/authorized_keys von sshd verarbeitet werden. Gültige Optionen sind yes, no oder eine Musterliste, die angibt, welche Umgebungsvariablennamen akzeptiert werden sollen (z. B. “LANG, LC_ *”). Der Standardwert ist no. Durch Aktivieren der Umgebungsverarbeitung können Benutzer in einigen Konfigurationen mithilfe von Mechanismen wie LD_PRELOAD Zugriffsbeschränkungen umgehen.

Compression

Gibt an, ob die Komprimierung aktiviert ist, nachdem sich der Benutzer erfolgreich authentifiziert hat. Das Argument muss yes, verzögert (ein altes Synonym für yes) oder no sein. Der Standardwert ist yes.

ClientAliveInterval

Legt ein Zeitlimit in Sekunden fest. Wenn keine Daten vom Client empfangen wurden, sendet sshd eine Nachricht über den verschlüsselten Kanal, um eine Antwort vom Client anzufordern. Der Standardwert ist 0, was darauf hinweist, dass diese Nachrichten nicht an den Client gesendet werden.

ClientAliveCountMax

Legt die Anzahl der aktiven Client-Nachrichten fest, die gesendet werden können, ohne dass sshd Nachrichten vom Client zurückerhält. Wenn dieser Schwellenwert erreicht wird, während Client-Alive-Nachrichten gesendet werden, trennt sshd den Client und beendet die Sitzung. Es ist wichtig zu beachten, dass sich die Verwendung von Client-Alive-Nachrichten stark von TCPKeepAlive unterscheidet. Die Client-Alive-Nachrichten werden über den verschlüsselten Kanal gesendet und sind daher nicht fälschbar. Die von TCPKeepAlive aktivierte TCP-Keepalive-Option ist fälschbar. Der Client-Alive-Mechanismus ist hilfreich, wenn der Client oder Server wissen muss, wann eine Verbindung nicht mehr reagiert.
Der Standardwert ist 3. Wenn ClientAliveInterval auf 15 festgelegt ist und ClientAliveCountMax auf dem Standardwert belassen wird, werden nicht reagierende SSH-Clients nach ca. 45 Sekunden getrennt. Das Setzen einer Null ClientAliveCountMax deaktiviert die Verbindungsbeendigung.

UseDNS

Gibt an, ob sshd den Namen des Remote-Hosts nachschlagen soll und ob der aufgelöste Hostname für die Remote-IP-Adresse wieder derselben IP-Adresse zugeordnet werden soll.
Wenn diese Option auf no gesetzt ist (Standardeinstellung), dürfen nur Adressen und keine Hostnamen in den Direktiven ~/.ssh/authorized_keys from und sshd_config Match Host verwendet werden.

PidFile

Gibt die Datei an, die die Prozess-ID des SSH-Dämons enthält, oder keine, um keine zu schreiben. Der Standardwert ist /var/run/sshd.pid.

MaxStartups

Gibt die maximale Anzahl gleichzeitiger nicht authentifizierter Verbindungen zum SSH-Dämon an. Zusätzliche Verbindungen werden getrennt, bis die Authentifizierung erfolgreich ist oder LoginGraceTime für eine Verbindung abläuft. Der Standardwert ist 10: 30: 100.
Alternativ kann ein zufälliges frühes Löschen aktiviert werden, indem die drei durch Doppelpunkte getrennten Werte start: rate: full (z. B. “10:30:60”) angegeben werden. sshd lehnt Verbindungsversuche mit einer Wahrscheinlichkeit von rate / 100 (30%) ab, wenn derzeit nicht authentifizierte Verbindungen gestartet werden. Die Wahrscheinlichkeit steigt linear an und alle Verbindungsversuche werden abgelehnt, wenn die Anzahl der nicht authentifizierten Verbindungen voll ist (60).

PermitTunnel

Gibt an, ob die Weiterleitung von tun-Geräten zulässig ist. Das Argument muss yes, Punkt-zu-Punkt (Schicht 3), Ethernet (Schicht 2) oder no sein. Die Angabe von yes ermöglicht sowohl Punkt-zu-Punkt als auch Ethernet. Der Standardwert ist no.
Unabhängig von dieser Einstellung müssen die Berechtigungen des ausgewählten tun-Geräts dem Benutzer Zugriff gewähren.

ChrootDirectory

Gibt den Pfadnamen eines Verzeichnisses an, in das nach der Authentifizierung chroot. Beim Start der Sitzung überprüft sshd, ob alle Komponenten des Pfadnamens Verzeichnisse im Root-Besitz sind, die von keinem anderen Benutzer oder keiner anderen Gruppe geschrieben werden können. Nach der Chroot ändert sshd das Arbeitsverzeichnis in das Ausgangsverzeichnis des Benutzers. Argumente für ChrootDirectory akzeptieren die im Abschnitt TOKENS beschriebenen Token.
Das ChrootDirectory muss die erforderlichen Dateien und Verzeichnisse enthalten, um die Sitzung des Benutzers zu unterstützen. Für eine interaktive Sitzung sind mindestens eine Shell, normalerweise sh und Basis- /Entwicklungsknoten wie null, null, stdin, stdout, stderr und erforderlich tty Geräte. Für Dateiübertragungssitzungen mit SFTP ist keine zusätzliche Konfiguration der Umgebung erforderlich, wenn der in Bearbeitung befindliche SFTP-Server verwendet wird. Für Sitzungen, die die Protokollierung verwenden, ist jedoch unter einigen Betriebssystemen möglicherweise /dev/log im Verzeichnis chroot erforderlich (siehe SFTP-Server für Details).
Aus Sicherheitsgründen ist es sehr wichtig, dass die Verzeichnishierarchie nicht durch andere Prozesse im System (insbesondere außerhalb des Gefängnisses) geändert wird. Eine Fehlkonfiguration kann zu unsicheren Umgebungen führen, die sshd nicht erkennen kann.
Der Standardwert ist none, was bedeutet, dass nicht chroot.

VersionAddendum

Gibt optional zusätzlichen Text an, der an das SSH-Protokollbanner angehängt werden soll, das vom Server bei der Verbindung gesendet wird. Der Standardwert ist none.

Der Inhalt der angegebenen Datei wird an den Remote Benutzer gesendet, bevor die Authentifizierung zulässig ist. Wenn das Argument keines ist, wird kein Banner angezeigt. Standardmäßig wird kein Banner angezeigt.

AcceptEnv

Gibt an, welche vom Client gesendeten Umgebungsvariablen in die Umgebung der Sitzung kopiert werden. Informationen zum Konfigurieren des Clients finden Sie unter SendEnv und SetEnv in ssh_config. Die Umgebungsvariable TERM wird immer dann akzeptiert, wenn der Client ein Pseudo-Terminal anfordert, wie es vom Protokoll gefordert wird. Variablen werden durch den Namen angegeben, der die Platzhalterzeichen “*” und “?” Enthalten kann. Mehrere Umgebungsvariablen können durch Leerzeichen getrennt oder auf mehrere AcceptEnv-Anweisungen verteilt werden. Seien Sie gewarnt, dass einige Umgebungsvariablen verwendet werden können, um eingeschränkte Benutzerumgebungen zu umgehen. Aus diesem Grund ist bei der Anwendung dieser Richtlinie Vorsicht geboten. Standardmäßig werden keine Umgebungsvariablen akzeptiert.

Subsystem

Konfiguriert ein externes Subsystem (z. B. einen Dateiübertragungsdämon). Argumente sollten ein Subsystemname und ein Befehl (mit optionalen Argumenten) sein, die auf Subsystemanforderung ausgeführt werden.
Der Befehl sftp-server implementiert das SFTP-Dateiübertragungssubsystem.
Alternativ implementiert der Name internal-sftp einen in Bearbeitung befindlichen SFTP-Server. Dies kann die Konfiguration mithilfe von ChrootDirectory vereinfachen, um Clients einen anderen Dateisystemstamm aufzuzwingen.
Standardmäßig sind keine Subsysteme definiert.

PasswordAuthentication

Gibt an, ob die Kennwortauthentifizierung zulässig ist. Der Standardwert ist yes.


System

Bei jeder Änderung, müssen sie SSHD neustarten.

sudo systemctl enable sshd
sudo systemctl start sshd
sudo systemctl stop sshd
sudo systemctl status sshd
sudo systemctl restart sshd
sudo systemctl disable sshd

Schreibe einen Kommentar

%d Bloggern gefällt das: