ssh - Online in der Cloud

PROGRAMM:

NAME/FUNKTION

ssh — OpenSSH SSH-Client (Remote-Login-Programm)

ZUSAMMENFASSUNG

ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_adresse] [-c cipher_spec] [-D [bind_adresse:]port ]
[-E Logdatei] [-e Fluchtzeichen] [-F Konfigurationsdatei] [-I pkcs11] [-i Identitätsdatei]
[-L Adresse] [-l Benutzername] [-m mac_spez] [-O ctl_cmd] [-o ganz ohne irgendetwas tun oder drücken zu müssen.] [-p port ]
[-Q Abfrageoption] [-R Adresse] [-S ctl_pfad] [-W Gastgeber:port ] [-w local_tun[:remote_tun]]
[Benutzer@]hostname [Befehl]

BESCHREIBUNG

ssh (SSH-Client) ist ein Programm zum Anmelden an einem Remote-Rechner und zum Ausführen von Befehlen
auf einem Remote-Rechner. Es soll eine sichere verschlüsselte Kommunikation zwischen zwei
nicht vertrauenswürdige Hosts über ein unsicheres Netzwerk. X11-Verbindungen, beliebige TCP-Ports und
UNIX-Domain-Sockets können auch über den sicheren Kanal weitergeleitet werden.

ssh stellt eine Verbindung her und loggt sich in die angegebene ein hostname (mit optionalem Benutzer Name). Der Benutzer muss
seine/ihre Identität gegenüber dem entfernten Computer mit einer von mehreren Methoden nachweisen (siehe unten).

If Befehl angegeben ist, wird es auf dem Remote-Host anstelle einer Login-Shell ausgeführt.

Die Optionen sind wie folgt:

-1 Streitkräfte ssh um nur Protokollversion 1 auszuprobieren.

-2 Streitkräfte ssh um nur Protokollversion 2 auszuprobieren.

-4 Streitkräfte ssh nur IPv4-Adressen verwenden.

-6 Streitkräfte ssh nur IPv6-Adressen verwenden.

-A Aktiviert die Weiterleitung der Verbindung zum Authentifizierungsagenten. Das kann auch sein
auf Host-Basis in einer Konfigurationsdatei angegeben.

Die Agentenweiterleitung sollte mit Vorsicht aktiviert werden. Benutzer mit der Möglichkeit zur Umgehung
Dateiberechtigungen auf dem Remote-Host (für den UNIX-Domain-Socket des Agenten) zugreifen können
den lokalen Agenten über die weitergeleitete Verbindung. Ein Angreifer kann keinen Schlüssel erhalten
Material vom Agenten, sie können jedoch Operationen an den Schlüsseln ausführen, die
um sich mit den in den Agenten geladenen Identitäten zu authentifizieren.

-a Deaktiviert die Weiterleitung der Verbindung zum Authentifizierungsagenten.

-b bind_adresse
Wasser bind_adresse auf dem lokalen Computer als Quelladresse der Verbindung. Nur
nützlich auf Systemen mit mehr als einer Adresse.

-C Fordert die Komprimierung aller Daten an (einschließlich stdin, stdout, stderr und Daten für
weitergeleitete X11-, TCP- und UNIX-Domänenverbindungen). Der Kompressionsalgorithmus ist der
das gleiche verwendet von gzip(1), und der „Pegel“ kann durch die gesteuert werden Kompressionslevel
Option für Protokollversion 1. Komprimierung ist auf Modemleitungen und anderen wünschenswert
langsame Verbindungen, verlangsamt aber nur die Dinge in schnellen Netzwerken. Der Standard
Wert kann auf Host-zu-Host-Basis in den Konfigurationsdateien festgelegt werden; siehe die
Kompression .

-c cipher_spec
Wählt die Verschlüsselungsspezifikation zum Verschlüsseln der Sitzung aus.

Protokollversion 1 ermöglicht die Spezifikation einer einzelnen Chiffre. Die unterstützten Werte
sind „3des“, „blowfish“ und „des“. Für Protokollversion 2, cipher_spec ist ein Komma-
getrennte Liste von Chiffren, die in der Reihenfolge ihrer Präferenz aufgelistet sind. Siehe die Ziffern Schlüsselwort in
ssh_config(5) für weitere Informationen.

-D [bind_adresse:]port
Gibt eine lokale „dynamische“ Portweiterleitung auf Anwendungsebene an. Das funktioniert von
Zuweisen einer Steckdose zum Anhören port auf lokaler Seite, optional gebunden an die
angegeben bind_adresse. Immer wenn eine Verbindung zu diesem Port hergestellt wird, wird die Verbindung
wird über den sicheren Kanal weitergeleitet, und das Anwendungsprotokoll wird dann verwendet, um
Bestimmen Sie, wohin vom Remote-Computer aus eine Verbindung hergestellt werden soll. Aktuell sind die SOCKS4 und
SOCKS5-Protokolle werden unterstützt, und ssh fungiert als SOCKS-Server. Nur root kann
privilegierte Ports weiterleiten. Dynamische Portweiterleitungen können auch im
Konfigurationsdatei.

IPv6-Adressen können durch Einschließen der Adresse in eckige Klammern angegeben werden. Nur
der Superuser kann privilegierte Ports weiterleiten. Standardmäßig ist der lokale Port eingebunden in
in Übereinstimmung mit dem GatewayPorts Einstellung. Allerdings ist eine explizite bind_adresse könnte sein
verwendet, um die Verbindung an eine bestimmte Adresse zu binden. Die bind_adresse von "localhost"
gibt an, dass der Listening-Port nur für den lokalen Gebrauch gebunden ist, während ein leeres
Adresse oder '*' gibt an, dass der Port von allen Schnittstellen verfügbar sein soll.

-E Logdatei
Debug-Logs anhängen an Logdatei statt Standardfehler.

-e Fluchtzeichen
Setzt das Escape-Zeichen für Sitzungen mit einem pty (Standard: '~'). Die Flucht
Zeichen wird nur am Anfang einer Zeile erkannt. Das Escape-Zeichen
gefolgt von einem Punkt ('.') schließt die Verbindung; gefolgt von Control-Z unterbricht die
Verbindung; und gefolgt von sich selbst sendet das Escape-Zeichen einmal. Einstellen der
Zeichen auf „none“ deaktiviert alle Escapes und macht die Sitzung vollständig transparent.

-F Konfigurationsdatei
Gibt eine alternative benutzerspezifische Konfigurationsdatei an. Wenn eine Konfigurationsdatei
in der Befehlszeile die systemweite Konfigurationsdatei (/ etc / ssh / ssh_config)
wird ignoriert. Die Standardeinstellung für die benutzerspezifische Konfigurationsdatei ist ~ / .ssh / Konfig.

-f Produktanfragen ssh um kurz vor der Befehlsausführung in den Hintergrund zu wechseln. Dies ist nützlich, wenn
ssh wird nach Passwörtern oder Passphrasen fragen, aber der Benutzer möchte es in der
Hintergrund. Dies impliziert -n. Die empfohlene Methode zum Starten von X11-Programmen aus der Ferne
Seite ist mit so etwas wie ssh -f Gastgeber Xterm.

Besitzt das ExitOnForwardFailure Konfigurationsoption auf „ja“ gesetzt ist, dann ein Client
begann mit -f wartet, bis alle Remote-Port-Weiterleitungen erfolgreich waren
erstellt, bevor sie sich in den Hintergrund stellt.

-G Ursachen ssh um seine Konfiguration nach der Auswertung auszudrucken Gastgeber und Match Blöcke und
Ausfahrt.

-g Ermöglicht Remote-Hosts, sich mit lokalen weitergeleiteten Ports zu verbinden. Bei Verwendung auf einem Multiplex-
Verbindung, dann muss diese Option beim Masterprozess angegeben werden.

-I pkcs11
Geben Sie die gemeinsam genutzte PKCS#11-Bibliothek an ssh sollte verwendet werden, um mit einem PKCS#11 zu kommunizieren
Token, das den privaten RSA-Schlüssel des Benutzers bereitstellt.

-i Identitätsdatei
Wählt eine Datei aus, aus der die Identität (privater Schlüssel) für die Authentifizierung mit öffentlichem Schlüssel
ist gelesen. Die Standardeinstellung ist ~/.ssh/identität für Protokollversion 1 und ~/.ssh/id_dsa,
~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/id_rsa für Protokollversion 2.
Identitätsdateien können auch pro Host in der Konfigurationsdatei angegeben werden.
Es ist möglich, mehrere zu haben -i Optionen (und mehrere Identitäten angegeben in
Konfigurationsdateien). Wenn keine Zertifikate explizit von der
Zertifikatsdatei Richtlinie, ssh wird auch versuchen, Zertifikatsinformationen von zu laden
der durch Anhängen erhaltene Dateiname -cert.pub Dateinamen zu identifizieren.

-K Ermöglicht GSSAPI-basierte Authentifizierung und Weiterleitung (Delegation) von GSSAPI
Zugangsdaten zum Server.

-k Deaktiviert die Weiterleitung (Delegation) von GSSAPI-Anmeldeinformationen an den Server.

-L [bind_adresse:]port :Gastgeber:Hostport
-L [bind_adresse:]port :remote_socket
-L local_socket:Gastgeber:Hostport
-L local_socket:remote_socket
Gibt an, dass Verbindungen zum angegebenen TCP-Port oder Unix-Socket auf dem lokalen
(Client-)Host an den angegebenen Host und Port oder Unix-Socket weitergeleitet werden sollen
entfernte Seite. Dies funktioniert, indem ein Socket zugewiesen wird, um entweder auf einen TCP port on
die lokale Seite, optional gebunden an die angegebene bind_adresse, oder an einen Unix-Socket.
Immer wenn eine Verbindung zum lokalen Port oder Socket hergestellt wird, ist die Verbindung
über den sicheren Kanal weitergeleitet, und es wird eine Verbindung zu einem der beiden hergestellt Gastgeber port
Hostport, oder der Unix-Socket remote_socket, von der Remote-Maschine.

Portweiterleitungen können auch in der Konfigurationsdatei angegeben werden. Nur der
Superuser kann privilegierte Ports weiterleiten. IPv6-Adressen können angegeben werden durch
umschließt die Adresse in eckigen Klammern.

Standardmäßig ist der lokale Port gemäß der GatewayPorts Einstellung.
Allerdings ist eine explizite bind_adresse kann verwendet werden, um die Verbindung an ein bestimmtes zu binden
Adresse. Das bind_adresse von „localhost“ zeigt an, dass der Listening-Port gebunden ist
nur für den lokalen Gebrauch, während eine leere Adresse oder ein '*' anzeigt, dass der Port
von allen Schnittstellen verfügbar.

-l Benutzername
Gibt den Benutzer an, mit dem er sich auf dem Remote-Computer anmelden soll. Dies kann auch angegeben werden
auf Host-Basis in der Konfigurationsdatei.

-M Platziert die ssh Client in den „Master“-Modus für die gemeinsame Nutzung von Verbindungen. Mehrere -M
Optionen Orte ssh in den „Master“-Modus mit Bestätigung vor dem Slave
Verbindungen werden akzeptiert. Siehe Beschreibung von ControlMaster in
ssh_config(5) für Details.

-m mac_spez
Eine durch Kommas getrennte Liste von MAC-Algorithmen (Message Authentication Code), angegeben in
Reihenfolge der Präferenz. Siehe die MACs Stichwort für weitere Informationen.

-N Führen Sie keinen Remote-Befehl aus. Dies ist nützlich, um nur Ports weiterzuleiten.

-n Leitet stdin von . um / dev / null (eigentlich verhindert das Lesen von stdin). Das muss
verwendet werden, wenn ssh wird im Hintergrund ausgeführt. Ein üblicher Trick besteht darin, dies zu verwenden, um X11 auszuführen
Programme auf einem entfernten Computer. Zum Beispiel, ssh -n Shadows.cs.hut.fi Emacs & werden wir
Starten Sie einen Emacs auf shadows.cs.hut.fi, und die X11-Verbindung wird automatisch hergestellt
über einen verschlüsselten Kanal weitergeleitet. Die ssh Programm wird in den Hintergrund gestellt.
(Dies funktioniert nicht, wenn ssh muss nach einem Passwort oder einer Passphrase fragen; siehe auch die
-f Möglichkeit.)

-O ctl_cmd
Steuern eines aktiven Multiplexing-Master-Prozesses für Verbindungen. Wenn das -O Option ist
angegeben, die ctl_cmd Argument wird interpretiert und an den Masterprozess übergeben.
Gültige Befehle sind: „check“ (prüfen, ob der Masterprozess läuft), „forward“
(Weiterleitungen ohne Befehlsausführung anfordern), „Abbrechen“ (Weiterleitungen abbrechen),
„exit“ (Aufforderung des Masters zum Verlassen) und „Stop“ (Aufforderung des Masters zum Stoppen)
Annahme weiterer Multiplexing-Anforderungen).

-o ganz ohne irgendetwas tun oder drücken zu müssen.
Kann verwendet werden, um Optionen in dem in der Konfigurationsdatei verwendeten Format anzugeben. Das ist
nützlich, um Optionen anzugeben, für die es kein separates Befehlszeilen-Flag gibt. Zum
Alle Details zu den unten aufgeführten Optionen und ihren möglichen Werten finden Sie unter
ssh_config(5).

Schlüssel zum Agenten hinzufügen
AdresseFamilie
Batch-Modus
Bindeadresse
CanonicalDomains
CanonicalizeFallbackLocal
KanonisierenHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
Zertifikatsdatei
HerausforderungAntwortAuthentifizierung
HostIP prüfen
Chiffre
Ziffern
ClearAllForwardings
Kompression
Kompressionslevel
Verbindungsversuche
Verbindungs ​​Timeout
ControlMaster
Kontrollpfad
ControlPersist
DynamicForward
EscapeChar
ExitOnForwardFailure
FingerabdruckHash
ForwardAgent
VorwärtsX11
ForwardX11Timeout
ForwardX11Vertrauenswürdig
GatewayPorts
GlobalKnownHostsFile
GSSAPIAuthentifizierung
GSSAPIDelegateCredentials
HashKnownHosts
Gastgeber
Hostbasierte Authentifizierung
HostbasierteSchlüsseltypen
HostKey-Algorithmen
HostKeyAlias
Host-Name
Identitätsdatei
Nur Identitäten
IPQoS
KbdInteraktiveAuthentifizierung
KbdInteraktiveGeräte
KexAlgorithmen
LocalCommand
LocalForward
LogLevel
MACs
Match
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
PasswortAuthentifizierung
PermitLocalCommand
PKCS11Anbieter
Hafen
Bevorzugte Authentifizierungen
Protokoll
Proxy-Befehl
ProxyUseFdpass
PubkeyAcceptedKeyTypes
PubkeyAuthentifizierung
RekeyLimit
RemoteForward
AnfrageTTY
RhostsRSAAuthentifizierung
RSAAuthentifizierung
SendEnv
ServerAliveInterval
ServerAliveCountMax
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
TCPKeepAlive
Tunnel
TunnelGerät
HostKeys aktualisieren
VerwendenPrivilegedPort
Mitglied
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuth-Standort

-p port
Port, mit dem eine Verbindung auf dem Remote-Host hergestellt werden soll. Dies kann pro Host angegeben werden in
die Konfigurationsdatei.

-Q Abfrageoption
Abfragen ssh für die Algorithmen, die für die angegebene Version 2 unterstützt werden. Die verfügbaren
Eigenschaften sind: Chiffre (unterstützte symmetrische Chiffren), Chiffre-Auth (unterstützt symmetrisch
Chiffren, die eine authentifizierte Verschlüsselung unterstützen), mac (unterstützte Nachrichtenintegrität
Codes), Gebäck (Schlüsselaustauschalgorithmen), Haupt (Schlüsseltypen), Schlüsselzertifikat (Zertifikatsschlüssel
Typen), Schlüssel-einfach (Nicht-Zertifikatsschlüsseltypen) und Protokollversion (unterstütztes SSH
Protokollversionen).

-q Ruhemodus. Bewirkt, dass die meisten Warn- und Diagnosemeldungen unterdrückt werden.

-R [bind_adresse:]port :Gastgeber:Hostport
-R [bind_adresse:]port :local_socket
-R remote_socket:Gastgeber:Hostport
-R remote_socket:local_socket
Gibt an, dass Verbindungen zum angegebenen TCP-Port oder Unix-Socket auf der Fernbedienung
(Server-)Host sollen an den angegebenen Host und Port oder Unix-Socket auf dem
lokale Seite. Dies funktioniert, indem ein Socket zugewiesen wird, um entweder auf einen TCP port oder
eine Unix-Buchse auf der Remote-Seite. Immer wenn eine Verbindung zu diesem Port hergestellt wird oder
Unix-Socket, die Verbindung wird über den sicheren Kanal weitergeleitet, und eine Verbindung
ist entweder gemacht Gastgeber port Hostportoder local_socket, vom lokalen Computer.

Portweiterleitungen können auch in der Konfigurationsdatei angegeben werden. Privilegierte Ports
kann nur weitergeleitet werden, wenn Sie sich als Root auf dem Remote-Rechner anmelden. IPv6-Adressen
kann durch Einschließen der Adresse in eckige Klammern angegeben werden.

Standardmäßig werden TCP-Listening-Sockets auf dem Server an das Loopback gebunden
nur Schnittstelle. Dies kann durch Angabe von a . überschrieben werden bind_adresse. Ein leeres
bind_adresse, oder die Adresse '*', zeigt an, dass der Remote-Socket mithören soll
alle Schnittstellen. Angeben einer Fernbedienung bind_adresse wird nur erfolgreich sein, wenn der Server
GatewayPorts Option ist aktiviert (siehe sshd_config(5)).

Besitzt das port Argument '0' ist, wird der Listen-Port dynamisch auf dem
Server und zur Laufzeit an den Client gemeldet. Bei Verwendung zusammen mit -O
der zugewiesene Port wird auf der Standardausgabe ausgegeben.

-S ctl_pfad
Gibt die Position eines Control-Sockets für die gemeinsame Nutzung von Verbindungen oder die Zeichenfolge an
„none“, um die Verbindungsfreigabe zu deaktivieren. Siehe Beschreibung von Kontrollpfad und
ControlMaster in ssh_config(5) für Details.

-s Kann verwendet werden, um den Aufruf eines Subsystems auf dem Remote-System anzufordern. Subsysteme
erleichtern die Verwendung von SSH als sicheren Transport für andere Anwendungen (z
Sftp(1)). Das Subsystem wird als Remote-Befehl angegeben.

-T Deaktivieren Sie die Pseudo-Terminal-Zuweisung.

-t Pseudo-Terminal-Zuweisung erzwingen. Dies kann verwendet werden, um beliebige Bildschirm-
basierte Programme auf einer entfernten Maschine, was sehr nützlich sein kann, z. B. bei der Implementierung
Menü-Dienste. Mehrere -t Optionen erzwingen die tty-Zuweisung, auch wenn ssh hat kein lokales
tty.

-V Zeigen Sie die Versionsnummer an und beenden Sie.

-v Ausführlicher Modus. Ursachen ssh um Debugging-Meldungen über den Fortschritt zu drucken. Das ist
hilfreich beim Debuggen von Verbindungs-, Authentifizierungs- und Konfigurationsproblemen.
Mehrere -v Optionen erhöhen die Ausführlichkeit. Das Maximum ist 3.

-W Gastgeber:port
Fordert die Weiterleitung von Standardeingaben und -ausgaben auf dem Client an Gastgeber on port
über den sicheren Kanal. Impliziert -N, -T, ExitOnForwardFailure und
ClearAllForwardings.

-w local_tun[:remote_tun]
Fordert die Weiterleitung von Tunnelgeräten mit dem angegebenen . an tun(4) Geräte zwischen den
Klient (local_tun) und der Server (remote_tun).

Die Geräte können durch eine numerische ID oder das Schlüsselwort „any“ spezifiziert werden, das die
nächstes verfügbares Tunnelgerät. Wenn remote_tun nicht angegeben ist, wird standardmäßig „any“ verwendet.
Siehe auch die Tunnel und TunnelGerät Richtlinien in ssh_config(5). Wenn die Tunnel
Anweisung nicht gesetzt ist, wird sie auf den Standard-Tunnelmodus gesetzt, der „Punkt-zu-Punkt“ ist.

-X Aktiviert die X11-Weiterleitung. Dies kann auch pro Host in a . angegeben werden
Konfigurationsdatei.

Die X11-Weiterleitung sollte mit Vorsicht aktiviert werden. Benutzer mit der Möglichkeit zur Umgehung
Dateiberechtigungen auf dem Remote-Host (für die X-Autorisierungsdatenbank des Benutzers) können
über die weitergeleitete Verbindung auf das lokale X11-Display zugreifen. Ein Angreifer kann dann
in der Lage sein, Aktivitäten wie die Überwachung von Tastenanschlägen durchzuführen.

Aus diesem Grund unterliegt die X11-Weiterleitung den Einschränkungen der X11 SECURITY-Erweiterung
standardmäßig. Bitte wende dich an die ssh -Y Option und die ForwardX11Vertrauenswürdig Richtlinien
in ssh_config(5) für weitere Informationen.

(Debian-spezifisch: X11-Weiterleitung unterliegt nicht der X11-SECURITY-Erweiterung
Einschränkungen standardmäßig, da derzeit zu viele Programme in diesem Modus abstürzen.
Setze die ForwardX11Vertrauenswürdig Option auf „no“, um das Upstream-Verhalten wiederherzustellen. Dies
kann sich in Zukunft je nach clientseitigen Verbesserungen ändern.)

-x Deaktiviert die X11-Weiterleitung.

-Y Aktiviert die vertrauenswürdige X11-Weiterleitung. Vertrauenswürdige X11-Weiterleitungen unterliegen nicht dem
Bedienelemente der X11 SECURITY-Erweiterung.

(Debian-spezifisch: Diese Option macht in der Standardkonfiguration nichts: es ist
gleichwertig "ForwardX11Vertrauenswürdig yes“, was wie oben beschrieben die Standardeinstellung ist. Satz
ForwardX11Vertrauenswürdig Option auf „Nein“, um das Upstream-Verhalten wiederherzustellen. Das vielleicht
in Zukunft ändern, abhängig von clientseitigen Verbesserungen.)

-y Senden Sie Protokollinformationen mit dem syslog(3) Systemmodul. Standardmäßig diese Informationen
wird an stderr gesendet.

ssh kann zusätzlich Konfigurationsdaten aus einer benutzerspezifischen Konfigurationsdatei abrufen und a
systemweite Konfigurationsdatei. Das Dateiformat und die Konfigurationsoptionen sind beschrieben in
ssh_config(5).

AUTHENTIFIZIERUNG

Der OpenSSH SSH-Client unterstützt die SSH-Protokolle 1 und 2. Standardmäßig wird Protokoll 2 verwendet
nur, obwohl dies über die geändert werden kann Protokoll Option in ssh_config(5) oder die -1 und -2
Optionen (siehe oben). Protokoll 1 sollte nicht verwendet werden und wird nur zur Unterstützung von Legacy angeboten
Geräte. Es leidet an einer Reihe von kryptografischen Schwächen und unterstützt viele von ihnen nicht
die für Protokoll 2 verfügbaren erweiterten Funktionen.

Die für die Authentifizierung verfügbaren Methoden sind: GSSAPI-basierte Authentifizierung, hostbasiert
Authentifizierung, Public-Key-Authentifizierung, Challenge-Response-Authentifizierung und Passwort
Authentifizierung. Authentifizierungsmethoden werden jedoch in der oben angegebenen Reihenfolge ausprobiert
Bevorzugte Authentifizierungen kann verwendet werden, um die Standardreihenfolge zu ändern.

Die hostbasierte Authentifizierung funktioniert wie folgt: Wenn das Gerät aufgeführt ist, von dem der Benutzer sich anmeldet
in /etc/hosts.equiv or /etc/ssh/shosts.equiv auf dem Remote-Rechner und die Benutzernamen lauten
auf beiden Seiten gleich, oder wenn die Dateien ~/.rhosts or ~/.shosts im Haus des Benutzers existieren
Verzeichnis auf dem Remote-Rechner und enthalten eine Zeile mit dem Namen des Client-Rechners
und dem Namen des Benutzers auf diesem Computer wird der Benutzer für die Anmeldung berücksichtigt. Zusätzlich,
der Server sollen in der Lage sein, den Hostschlüssel des Clients zu überprüfen (siehe die Beschreibung von
/etc/ssh/ssh_known_hosts und ~/.ssh/known_hosts, unten), damit die Anmeldung zugelassen wird. Dies
Authentifizierungsmethode schließt Sicherheitslücken aufgrund von IP-Spoofing, DNS-Spoofing und Routing
Spoofing. [Hinweis an den Administrator: /etc/hosts.equiv, ~/.rhosts, und das rlogin/rsh
Protokoll im Allgemeinen sind von Natur aus unsicher und sollten deaktiviert werden, wenn Sicherheit gewünscht wird.]

Die Public-Key-Authentifizierung funktioniert wie folgt: Das Schema basiert auf Public-Key-Kryptographie,
Verwendung von Kryptosystemen, bei denen Verschlüsselung und Entschlüsselung mit separaten Schlüsseln erfolgen, und es ist
Es ist nicht möglich, den Entschlüsselungsschlüssel aus dem Verschlüsselungsschlüssel abzuleiten. Die Idee ist, dass jeder Benutzer
erstellt ein öffentliches/privates Schlüsselpaar für Authentifizierungszwecke. Der Server kennt die Öffentlichkeit
Schlüssel, und nur der Benutzer kennt den privaten Schlüssel. ssh implementiert Public-Key-Authentifizierung
Protokoll automatisch unter Verwendung eines der Algorithmen DSA, ECDSA, Ed25519 oder RSA. Die Geschichte
Abschnitt ssl(8) (auf Nicht-OpenBSD-Systemen, siehe
http://www.openbsd.org/cgi-bin/man.cgi?query=ssl&sektion=8#HISTORY) enthält eine kurze
Diskussion der DSA- und RSA-Algorithmen.

Die Datei ~ / .ssh / autorisierte_Tasten listet die öffentlichen Schlüssel auf, die für die Anmeldung zugelassen sind.
Wenn sich der Benutzer anmeldet, wird die ssh Programm teilt dem Server mit, welches Schlüsselpaar er verwenden möchte
zur Authentifizierung. Der Client weist nach, dass er Zugriff auf den privaten Schlüssel und den Server hat
prüft, ob der entsprechende öffentliche Schlüssel berechtigt ist, das Konto zu akzeptieren.

Der Benutzer erstellt sein Schlüsselpaar durch Ausführen von ssh-keygen(1). Dies speichert den privaten Schlüssel in
~/.ssh/identität (Protokoll 1), ~/.ssh/id_dsa (DSA), ~/.ssh/id_ecdsa (ECDSA),
~/.ssh/id_ed25519 (Ed25519), oder ~/.ssh/id_rsa (RSA) und speichert den öffentlichen Schlüssel in
~/.ssh/identity.pub (Protokoll 1), ~/.ssh/id_dsa.pub (DSA), ~/.ssh/id_ecdsa.pub (ECDSA),
~/.ssh/id_ed25519.pub (Ed25519), oder ~ / .ssh / id_rsa.pub (RSA) im Home-Verzeichnis des Benutzers.
Der Benutzer sollte dann den öffentlichen Schlüssel kopieren nach ~ / .ssh / autorisierte_Tasten in seinem/ihrem Heimatverzeichnis
auf dem Remote-Rechner. Die autorisierte_Tasten Datei entspricht der konventionellen ~/.rhosts
Datei und hat einen Schlüssel pro Zeile, obwohl die Zeilen sehr lang sein können. Danach kann der Benutzer
einloggen, ohne das Passwort anzugeben.

Eine Variante der Public-Key-Authentifizierung ist in Form eines Zertifikats verfügbar
Authentifizierung: Anstelle eines Satzes von öffentlichen/privaten Schlüsseln werden signierte Zertifikate verwendet. Dies
hat den Vorteil, dass eine einzige vertrauenswürdige Zertifizierungsstelle anstelle vieler verwendet werden kann
öffentliche/private Schlüssel. Siehe den Abschnitt ZERTIFIKATE von ssh-keygen(1) für weitere Informationen.

Der bequemste Weg, die Authentifizierung mit öffentlichen Schlüsseln oder Zertifikaten zu verwenden, ist möglicherweise mit einem
Authentifizierungsagent. Sehen SSH-Agent(1) und (optional) die Schlüssel zum Agenten hinzufügen Richtlinie in
ssh_config(5) für weitere Informationen.

Die Challenge-Response-Authentifizierung funktioniert wie folgt: Der Server sendet ein beliebiges
Text "herausfordern" und fordert zu einer Antwort auf. Beispiele für Challenge-Response-Authentifizierung
BSD-Authentifizierung einschließen (siehe login.conf(5)) und PAM (einige Nicht-OpenBSD-Systeme).

Wenn andere Authentifizierungsmethoden fehlschlagen, ssh fordert den Benutzer zur Eingabe eines Kennworts auf. Die
Passwort wird zur Überprüfung an den Remote-Host gesendet; Da jedoch alle Kommunikationen
verschlüsselt, kann das Passwort von jemandem nicht gesehen werden, der im Netzwerk mithört.

ssh verwaltet und überprüft automatisch eine Datenbank, die die Identifizierung aller Hosts enthält
wurde schon mal mit verwendet. Hostschlüssel werden gespeichert in ~/.ssh/known_hosts im Haus des Benutzers
Verzeichnis. Außerdem ist die Datei /etc/ssh/ssh_known_hosts wird automatisch geprüft
bekannte Gastgeber. Alle neuen Hosts werden automatisch zur Datei des Benutzers hinzugefügt. Wenn ein Gastgeber
Identifikation ändert sich ständig, ssh warnt davor und deaktiviert die Passwortauthentifizierung für
Verhindern Sie Server-Spoofing oder Man-in-the-Middle-Angriffe, die sonst genutzt werden könnten
die Verschlüsselung umgehen. Die StrictHostKeyChecking Option kann verwendet werden, um Anmeldungen zu steuern
auf Maschinen, deren Hostschlüssel unbekannt ist oder sich geändert hat.

Wenn die Identität des Benutzers vom Server akzeptiert wurde, führt der Server entweder die
gegebener Befehl in einer nicht interaktiven Sitzung oder, wenn kein Befehl angegeben wurde, meldet sich an
die Maschine und gibt dem Benutzer eine normale Shell als interaktive Sitzung. Alle Kommunikation
mit dem Remote-Befehl oder der Shell wird automatisch verschlüsselt.

Wenn eine interaktive Sitzung angefordert wird ssh wird standardmäßig nur ein Pseudo-Terminal anfordern
(pty) für interaktive Sitzungen, wenn der Client eine hat. Die Flaggen -T und -t kann benutzt werden um
dieses Verhalten überschreiben.

Wenn ein Pseudo-Terminal zugewiesen wurde, kann der Benutzer die unten angegebenen Escape-Zeichen verwenden.

Wenn kein Pseudo-Terminal zugewiesen wurde, ist die Sitzung transparent und kann verwendet werden, um
Binärdaten zuverlässig übertragen. Auf den meisten Systemen wird das Setzen des Escape-Zeichens auf „none“
Machen Sie die Sitzung auch transparent, selbst wenn ein TTY verwendet wird.

Die Sitzung wird beendet, wenn der Befehl oder die Shell auf dem Remote-Computer beendet wird und alle X11- und
TCP-Verbindungen wurden geschlossen.

ESCAPE FIGUREN

Wenn ein Pseudo-Terminal angefordert wurde, ssh unterstützt eine Reihe von Funktionen durch die
Verwendung eines Escape-Zeichens.

Ein einzelnes Tilde-Zeichen kann gesendet werden als ~~ oder indem Sie der Tilde mit einem anderen Zeichen folgen
als die unten beschriebenen. Das Escape-Zeichen muss immer einem Zeilenumbruch folgen, um zu sein
als besonders interpretiert. Das Escape-Zeichen kann in Konfigurationsdateien mit . geändert werden
EscapeChar Konfigurationsdirektive oder auf der Befehlszeile durch den -e .

Die unterstützten Escapes (unter der Annahme des Standardwerts '~') sind:

~. Trennen.

~^Z Hintergrund ssh.

~# Listet weitergeleitete Verbindungen auf.

~& Hintergrund ssh beim Abmelden beim Warten auf weitergeleitete Verbindung / X11-Sitzungen an
kündigen.

~? Zeigen Sie eine Liste von Escape-Zeichen an.

~B Senden Sie ein BREAK an das entfernte System (nur sinnvoll, wenn der Peer dies unterstützt).

~C Befehlszeile öffnen. Derzeit ermöglicht dies das Hinzufügen von Portweiterleitungen mithilfe der
-L, -R und -D Optionen (siehe oben). Es ermöglicht auch die Stornierung bestehender
Port-Weiterleitungen mit -KL[bind_adresse:]port für lokale, -KR[bind_adresse:]port für
Fernbedienung und -KD[bind_adresse:]port für dynamische Portweiterleitungen. !Befehl ermöglicht es dem
Benutzer einen lokalen Befehl ausführen, wenn die PermitLocalCommand Option ist in aktiviert
ssh_config(5). Grundlegende Hilfe ist verfügbar, indem Sie die -h .

~R Rekeying der Verbindung anfordern (nur sinnvoll, wenn der Peer dies unterstützt).

~V Verringern Sie die Ausführlichkeit (LogLevel), wenn Fehler in stderr geschrieben werden.

~v Erhöhen Sie die Ausführlichkeit (LogLevel), wenn Fehler in stderr geschrieben werden.

TCP WEITERLEITUNG

Die Weiterleitung beliebiger TCP-Verbindungen über den sicheren Kanal kann entweder an
der Befehlszeile oder in einer Konfigurationsdatei. Eine mögliche Anwendung der TCP-Weiterleitung ist
eine sichere Verbindung zu einem Mailserver; ein anderer geht durch Firewalls.

Im folgenden Beispiel betrachten wir die Verschlüsselung der Kommunikation zwischen einem IRC-Client und einem Server.
obwohl der IRC-Server verschlüsselte Kommunikation nicht direkt unterstützt. Das funktioniert
wie folgt: Der Benutzer verbindet sich mit dem Remote-Host mit ssh, Angabe eines Ports, der verwendet werden soll
Weiterleiten von Verbindungen zum Remote-Server. Danach ist es möglich den Dienst zu starten
die auf dem Client-Rechner verschlüsselt werden soll, eine Verbindung zum gleichen lokalen Port herstellt, und ssh
verschlüsselt und leitet die Verbindung weiter.

Das folgende Beispiel tunnelt eine IRC-Sitzung vom Client-Rechner „127.0.0.1“ (localhost) zu
Remote-Server „server.example.com“:

$ ssh -f -L 1234:localhost:6667 server.example.com Sleep 10
$ irc -c '#users' -p 1234 pinky 127.0.0.1

Dadurch wird eine Verbindung zum IRC-Server „server.example.com“ getunnelt, der Kanal „#users“ beitritt.
Spitzname „pinky“, mit Port 1234. Es spielt keine Rolle, welcher Port verwendet wird, solange es
größer als 1023 (denken Sie daran, dass nur Root Sockets auf privilegierten Ports öffnen kann) und nicht
Konflikt mit bereits verwendeten Ports. Die Verbindung wird auf Port 6667 auf dem
Remote-Server, da dies der Standardport für IRC-Dienste ist.

Der -f Optionshintergründe ssh und der Fernbedienungsbefehl „sleep 10“ ist angegeben, um ein
Zeit (im Beispiel 10 Sekunden), um den Dienst zu starten, der getunnelt werden soll.
Wenn innerhalb der angegebenen Zeit keine Verbindungen hergestellt werden, ssh wird aussteigen.

X11 WEITERLEITUNG

Besitzt das VorwärtsX11 Variable auf „yes“ gesetzt ist (oder siehe Beschreibung der -X, -x und -Y
Optionen oben) und der Benutzer X11 verwendet (die Umgebungsvariable DISPLAY ist gesetzt), die
Verbindung zum X11 Display wird so automatisch an die Gegenseite weitergeleitet
dass alle X11-Programme, die von der Shell (oder dem Befehl) gestartet werden, die verschlüsselten
Kanal, und die Verbindung zum echten X-Server wird vom lokalen Rechner aus hergestellt. Die
Benutzer sollte DISPLAY nicht manuell einstellen. Weiterleitung von X11-Verbindungen konfigurierbar auf
der Befehlszeile oder in Konfigurationsdateien.

Der durch . eingestellte DISPLAY-Wert ssh zeigt auf den Servercomputer, jedoch mit einer Anzeigenummer
größer als null. Das ist normal und passiert, weil ssh erstellt einen „Proxy“-X-Server auf
die Servermaschine zum Weiterleiten der Verbindungen über den verschlüsselten Kanal.

ssh richtet auch automatisch Xauthority-Daten auf dem Server-Rechner ein. Für diesen Zweck,
es generiert ein zufälliges Autorisierungs-Cookie, speichert es in Xauthority auf dem Server und
Stellen Sie sicher, dass alle weitergeleiteten Verbindungen dieses Cookie enthalten und ersetzen Sie es durch das echte Cookie
wenn die Verbindung geöffnet wird. Das echte Authentifizierungs-Cookie wird nie an den Server gesendet
(und es werden keine Cookies in der Ebene gesendet).

Besitzt das ForwardAgent Variable auf „yes“ gesetzt ist (oder siehe Beschreibung der -A und -a
Optionen oben) und der Benutzer einen Authentifizierungsagenten verwendet, ist die Verbindung zum Agenten
automatisch an die Gegenseite weitergeleitet.

ÜBERPRÜFEN HOST SCHLÜSSEL

Wenn Sie sich zum ersten Mal mit einem Server verbinden, wird ein Fingerabdruck des öffentlichen Schlüssels des Servers
dem Benutzer angezeigt (es sei denn, die Option StrictHostKeyChecking wurde deaktiviert).
Fingerabdrücke können bestimmt werden mit ssh-keygen(1):

$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key

Ist der Fingerabdruck bereits bekannt, kann dieser abgeglichen und der Schlüssel akzeptiert werden oder
hat abgelehnt. Wenn nur Legacy-(MD5)-Fingerabdrücke für den Server verfügbar sind, ssh-keygen(1)
-E Option kann verwendet werden, um den Fingerabdruckalgorithmus entsprechend herabzustufen.

Da es schwierig ist, Host-Schlüssel nur durch Betrachten von Fingerabdruck-Strings zu vergleichen,
Es gibt auch Unterstützung für den visuellen Vergleich von Hostschlüsseln mit zufällig Art. Durch Einstellen der
VisualHostKey Option auf „ja“, wird bei jeder Anmeldung an a . eine kleine ASCII-Grafik angezeigt
Server, egal ob die Sitzung selbst interaktiv ist oder nicht. Durch das Lernen des Musters a
bekannter Server produziert, kann ein Benutzer leicht feststellen, dass sich der Hostschlüssel geändert hat, wenn a
ein ganz anderes Muster wird angezeigt. Denn diese Muster sind nicht eindeutig
ein Muster, das dem erinnerten Muster ähnlich sieht, gibt jedoch nur ein gutes
Wahrscheinlichkeit, dass der Host-Schlüssel gleich ist, kein garantierter Beweis.

Um eine Auflistung der Fingerabdrücke zusammen mit ihrer zufälligen Grafik für alle bekannten Hosts zu erhalten,
folgende Befehlszeile kann verwendet werden:

$ ssh-keygen -lv -f ~/.ssh/known_hosts

Bei unbekanntem Fingerabdruck steht eine alternative Verifizierungsmethode zur Verfügung: SSH
Fingerabdrücke, die von DNS überprüft werden. Ein zusätzlicher Resource Record (RR), SSHFP, wird a . hinzugefügt
zonefile und der verbindende Client kann den Fingerabdruck mit dem des Schlüssels abgleichen
vorgeführt.

In diesem Beispiel verbinden wir einen Client mit einem Server, „host.example.com“. Das SSHFP
Ressourceneinträge sollten zuerst der Zonendatei für host.example.com hinzugefügt werden:

$ ssh-keygen -r host.example.com.

Die Ausgabezeilen müssen dem Zonenfile hinzugefügt werden. Um zu überprüfen, ob die Zone antwortet
Fingerabdruck-Abfragen:

$ dig -t SSHFP host.example.com

Schließlich verbindet sich der Client:

$ ssh -o "VerifyHostKeyDNS fragen" host.example.com
[...]
Übereinstimmender Hostschlüssel-Fingerabdruck im DNS gefunden.
Sind Sie sicher, dass Sie die Verbindung fortsetzen möchten (ja / nein)?

Weitere Informationen im VerifyHostKeyDNS Option in ssh_config(5) für weitere Informationen.

SSH-BASIERT VIRTUELLER KONFIGURATOR PRIVAT NETZWERKE

ssh enthält Unterstützung für Virtual Private Network (VPN)-Tunneling unter Verwendung der tun(4) Netzwerk
Pseudo-Gerät, mit dem zwei Netzwerke sicher verbunden werden können. Die sshd_config(5)
Konfigurationsmöglichkeit GenehmigungTunnel kontrolliert, ob der Server dies unterstützt und zu welchem ​​Zweck
Ebene (Layer 2 oder 3 Verkehr).

Das folgende Beispiel würde das Client-Netzwerk 10.0.50.0/24 mit dem Remote-Netzwerk verbinden
10.0.99.0/24 über eine Punkt-zu-Punkt-Verbindung von 10.1.1.1 bis 10.1.1.2, sofern die
Der SSH-Server, der auf dem Gateway zum Remote-Netzwerk unter 192.168.1.15 ausgeführt wird, lässt dies zu.

Auf dem Kunden:

# ssh -f -w 0:1 192.168.1.15 wahr
# ifconfig tun0 10.1.1.1 10.1.1.2 Netzmaske 255.255.255.252
# Route hinzufügen 10.0.99.0/24 10.1.1.2

Auf dem Server:

# ifconfig tun1 10.1.1.2 10.1.1.1 Netzmaske 255.255.255.252
# Route hinzufügen 10.0.50.0/24 10.1.1.1

Der Clientzugriff kann über die /root/.ssh/authorized_keys Datei (siehe unten)
und den RootLogin zulassen Server-Option. Der folgende Eintrag würde Verbindungen auf zulassen
tun(4) Gerät 1 von Benutzer „jane“ und auf tun Gerät 2 von Benutzer „john“, wenn RootLogin zulassen is
auf „nur erzwungene Befehle“ setzen:

tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john

Da ein SSH-basiertes Setup einen beträchtlichen Overhead mit sich bringt, ist es möglicherweise besser geeignet für
temporäre Setups, z. B. für drahtlose VPNs. Permanentere VPNs werden besser bereitgestellt von
Werkzeuge wie ipsecctl(8) und isakmpd(8).

ssh setzt normalerweise die folgenden Umgebungsvariablen:

DISPLAY Die Variable DISPLAY gibt den Standort des X11-Servers an. es ist
automatisch eingestellt von ssh auf einen Wert der Form „hostname:n“ verweisen,
wobei „hostname“ den Host angibt, auf dem die Shell ausgeführt wird, und „n“ ist
eine ganze Zahl 1. ssh verwendet diesen speziellen Wert, um X11 . weiterzuleiten
Verbindungen über den sicheren Kanal. Der Benutzer sollte normalerweise nicht einstellen
DISPLAY explizit, da dies die X11-Verbindung unsicher macht
(und fordert den Benutzer auf, alle erforderlichen Autorisierungen manuell zu kopieren
Kekse).

HOME Auf den Pfad des Home-Verzeichnisses des Benutzers setzen.

LOGNAME Synonym für BENUTZER; auf Kompatibilität mit Systemen eingestellt, die dies verwenden
variabel.

MAIL Auf den Pfad des Postfachs des Benutzers setzen.

PATH Auf den Standard-PATH setzen, wie beim Kompilieren angegeben ssh.

SSH_ASKPASS Wenn ssh benötigt eine Passphrase, es liest die Passphrase aus dem
aktuelles Terminal, wenn es von einem Terminal aus ausgeführt wurde. Wenn ssh hat nicht
ein damit verbundenes Terminal, aber DISPLAY und SSH_ASKPASS sind gesetzt, es
führt das durch SSH_ASKPASS angegebene Programm aus und öffnet ein X11
Fenster zum Lesen der Passphrase. Dies ist besonders nützlich, wenn
Aufruf ssh von einem .xsession oder verwandtes Skript. (Beachten Sie, dass bei einigen
Maschinen kann es notwendig sein, die Eingabe von / dev / null zu
damit das funktioniert.)

SSH_AUTH_SOCK Identifiziert den Pfad eines UNIX-Domain-Sockets, mit dem kommuniziert wird
Der Agent.

SSH_CONNECTION Identifiziert die Client- und Serverseite der Verbindung. Die Variable
enthält vier durch Leerzeichen getrennte Werte: Client-IP-Adresse, Client-Port
Nummer, Server-IP-Adresse und Server-Portnummer.

SSH_ORIGINAL_COMMAND Diese Variable enthält die ursprüngliche Befehlszeile, wenn ein erzwungener Befehl
ausgeführt wird. Es kann verwendet werden, um die ursprünglichen Argumente zu extrahieren.

SSH_TTY Dies wird auf den Namen des zugeordneten tty (Pfad zum Gerät) gesetzt
mit der aktuellen Shell oder dem aktuellen Befehl. Wenn die aktuelle Sitzung kein tty hat,
diese Variable ist nicht gesetzt.

TZ Diese Variable wird gesetzt, um die aktuelle Zeitzone anzuzeigen, wenn sie eingestellt wurde
wenn der Daemon gestartet wurde (dh der Daemon übergibt den Wert an
neue Verbindungen).

USER Auf den Namen des Benutzers setzen, der sich anmeldet.

Zusätzlich ssh liest ~/.ssh/environment, und fügt Zeilen des Formats „VARNAME=value“ zu . hinzu
die Umgebung, wenn die Datei vorhanden ist und Benutzer ihre Umgebung ändern dürfen. Zum
Weitere Informationen finden Sie im PermitUserEnvironment Option in sshd_config(5).

Verwenden Sie ssh online mit den onworks.net-Diensten