Sichere Schale

Das Sichern Sie das Shell -Protokoll (Ssh) ist ein kryptografisch Netzwerkprotokoll zum Betrieb Netzwerkdienste sicher über einem ungesicherten Netzwerk.^[1] Die bemerkenswertesten Anwendungen sind abgelegen Anmeldung und Befehlszeile Hinrichtung.

SSH -Anwendungen basieren auf einem Kundenserver Architektur, verbinden eine SSH -Kunde Instanz mit an SSH -Server.^[2] SSH arbeitet als geschichtete Protokollsuite mit drei Haupt hierarchischen Komponenten: die Transportschicht Bietet Serverauthentifizierung, Vertraulichkeit und Integrität; das Benutzerauthentifizierungsprotokoll Validiert den Benutzer auf dem Server. und die Verbindungsprotokoll Multiplexen Sie den verschlüsselten Tunnel in mehrere logische Kommunikationskanäle.^[1]

SSH wurde auf Unix-artig Betriebssysteme als Ersatz für Telnet und für ungesichert Fernbedienung Unix Shell Protokolle wie Berkeley Fernschale (RSH) und die verwandten Rlogin und Rexec Protokolle, die alle unsicher verwenden, Klartext Übertragung von Authentifizierungs -Token.

SSH wurde 1995 vom finnischen Informatiker Tatu Ylönen entworfen. Die anschließende Entwicklung der Protokollsuite verlief in mehreren Entwicklergruppen und führte zu verschiedenen Implementierungsvarianten. Die Protokollspezifikation unterscheidet zwei Hauptversionen, die als SSH-1 und SSH-2 bezeichnet werden. Der am häufigsten implementierte Software -Stack ist OpenSSH, veröffentlicht 1999 als Open-Source-Software von der OpenBSD Entwickler. Implementierungen werden für alle Arten von Betriebssystemen verteilt, einschließlich eingebetteter Systeme.

Definition

SSH verwendet Kryptographie der Öffentlichkeit zu authentifizieren Der Remote -Computer und ermöglicht es, den Benutzer gegebenenfalls authentifiziert zu haben.^[2]

SSH kann in mehreren Methoden verwendet werden. In einfacher Weise verwenden beide Enden eines Kommunikationskanals automatisch generierte öffentlich-private Schlüsselpaare, um eine Netzwerkverbindung zu verschlüsseln, und verwenden dann a Passwort um den Benutzer zu authentifizieren.

Wenn das öffentlich-private Schlüsselpaar vom Benutzer manuell generiert wird, wird die Authentifizierung im Wesentlichen ausgeführt, wenn das Schlüsselpaar erstellt wird, und eine Sitzung kann dann automatisch ohne Passwortaufforderung geöffnet werden. In diesem Szenario befindet sich der öffentliche Schlüssel auf alle Computer, die den Zugriff auf den Eigentümer des passenden privaten Schlüssels ermöglichen müssen, den der Eigentümer privat hält. Während die Authentifizierung auf dem privaten Schlüssel basiert, wird der Schlüssel während der Authentifizierung nie über das Netzwerk übertragen. SSH überprüft nur, dass dieselbe Person, die den öffentlichen Schlüssel anbietet, auch den passenden privaten Schlüssel besitzt.

In allen Versionen von SSH ist es wichtig, unbekannt zu überprüfen öffentliche Schlüssel, d.h. Verbinden Sie die öffentlichen Schlüssel mit Identitäten, bevor sie sie als gültig annehmen. Wenn Sie den öffentlichen Schlüssel eines Angreifers ohne Validierung akzeptieren, wird ein nicht autorisierter Angreifer als gültiger Benutzer genehmigt.

Authentifizierung: OpenSSH Key Management

An Unix-artig Systeme, die Liste der autorisierten öffentlichen Schlüssel, wird normalerweise im Home -Verzeichnis des Benutzers gespeichert, der sich in der Datei ~/.ssh/autorized_keys aus der Ferne anmelden darf.^[3] Diese Datei wird von SSH nur dann respektiert, wenn sie nicht von dem Eigentümer und der Wurzel geschrieben werden kann. Wenn der öffentliche Schlüssel am Remote -Ende vorhanden ist und der passende private Schlüssel am lokalen Ende vorhanden ist, ist das Eingeben des Kennworts nicht mehr erforderlich. Für zusätzliche Sicherheit kann der private Schlüssel selbst jedoch mit einer Passphrase gesperrt werden.

Der private Schlüssel kann auch an Standardstellen gesucht werden, und sein vollständiger Pfad kann als Befehlszeileneinstellung angegeben werden (die Option -ich für SSH). Das ssh-keygen Der Versorgungsunternehmen produziert die öffentlichen und privaten Schlüssel, immer paarweise.

SSH unterstützt auch eine passbasierte Authentifizierung, die durch automatisch generierte Schlüssel verschlüsselt wird. In diesem Fall könnte der Angreifer die legitime Serverseite nachahmen, nach dem Passwort fragen und sie erhalten ((Mann-in-the-Middle-Angriff). Dies ist jedoch nur möglich, wenn die beiden Seiten noch nie zuvor authentifiziert wurden, da sich SSH an den Schlüssel erinnert, den die Serverseite zuvor verwendet hat. Der SSH -Client wird eine Warnung anregen, bevor der Schlüssel eines neuen, bisher unbekannten Servers akzeptiert wird. Die Kennwortauthentifizierung kann von der Serverseite deaktiviert werden.

Verwenden

SSH wird normalerweise verwendet, um sich in einem Remote -Computer anzumelden und Befehle auszuführen, aber es unterstützt es auch Tunneling, Weiterleitung TCP -Ports und X11 Verbindungen; Es kann Dateien mithilfe der zugehörigen übertragen SSH -Dateiübertragung (SFTP) oder Sichere Kopie (SCP) Protokolle.^[2] SSH verwendet das Client -Server -Modell.

Ein SSH Klient Das Programm wird in der Regel zum Herstellen von Verbindungen zu einem SSH verwendet Dämon Remoteverbindungen akzeptieren. Beide sind häufig in den meisten modernen vorhanden Betriebssysteme, einschließlich Mac OS, die meisten Verteilungen von Linux, OpenBSD, Freebsd, Netbsd, Solaris und OpenVMS. Insbesondere Versionen von Fenster Vor der Windows 10 Version 1709 enthalten SSH standardmäßig nicht. Proprietär, Freeware und Open Source (z.B. Kitt,^[4] und die Version von OpenSSH Welches ist Teil von Cygwin^[5]) Versionen verschiedener Ebenen der Komplexität und Vollständigkeit existieren. Dateimanager für Unix-ähnliche Systeme (z. Konqueror) kann die verwenden FISCHE Protokoll, um eine G-G-GUI mit Drag-and-Drop bereitzustellen. Das Open Source Windows -Programm WinSCP^[6] Bietet eine ähnliche Dateiverwaltung (Synchronisation, Kopie, Remote-Löschdelete) mit Putty als Back-End. Beide WinSCP^[7] und Kitt^[8] sind verpackt, um direkt von einem USB -Laufwerk auszuführen, ohne dass eine Installation auf dem Client -Computer erforderlich ist. Das Einrichten eines SSH -Servers in Windows umfasst normalerweise die Aktivierung einer Funktion in der Einstellungs -App. Im Windows 10 Version 1709Ein offizieller Win32 -Hafen von OpenSSH ist verfügbar.

SSH ist wichtig in Cloud Computing Um Konnektivitätsprobleme zu lösen, vermeiden Sie die Sicherheitsprobleme bei der Aufdeckung eines Cloud-basierten virtuellen Computers direkt im Internet. Ein SSH -Tunnel kann einen sicheren Weg über das Internet über eine Firewall zu einer virtuellen Maschine bieten.^[9]

Das Iana hat zugewiesen TCP Hafen 22, UDP Port 22 und SCTP Port 22 für dieses Protokoll.^[10] Iana hatte den Standard -TCP -Port 22 für SSH -Server als einen der von Bekannte Ports Bereits 2001.^[11] SSH kann auch verwendet werden SCTP eher als TCP als verbindungsorientierte Transportschichtprotokoll.^[12]

Historische Entwicklung

Version 1

Im Jahr 1995, Tatu Ylönen, ein Forscher bei Helsinki Universität für Technologie, Finnland, entwarf die erste Version des Protokolls (jetzt genannt SSH-1) durch ein Passwort aufgefordert.schnüffeln Angriff auf sein Universitätsnetzwerk.^[13] Das Ziel von SSH war es, das frühere zu ersetzen Rlogin, Telnet, Ftp^[14] und rsh Protokolle, die weder eine starke Authentifizierung lieferten noch die Vertraulichkeit garantieren. Ylönen veröffentlichte seine Umsetzung als Freeware Im Juli 1995 und das Werkzeug erlangten schnell an Popularität. Gegen Ende 1995 war die SSH -Benutzerbasis auf 20.000 Benutzer in fünfzig Ländern gewachsen.

Im Dezember 1995 gründete Ylönen SSH Communications Security, um SSH zu vermarkten und zu entwickeln. Die Originalversion der SSH -Software verwendete verschiedene Teile von gratis Software, wie zum Beispiel Gnu libgmp, aber spätere Versionen, die von SSH Communications Security veröffentlicht wurden proprietäre Software.

Es wurde geschätzt, dass bis 2000 die Anzahl der Benutzer auf 2 Millionen angewachsen war.^[15]

Version 2

"Secsh" war der Beamte Internet Engineering Task Force der Internet Engineering (IETF) Name für die IETF -Arbeitsgruppe, die für Version 2 des SSH -Protokolls verantwortlich ist.^[16] Im Jahr 2006 eine überarbeitete Version des Protokolls, SSH-2, wurde als Standard übernommen. Diese Version ist mit SSH-1 nicht kompatibel. SSH-2 bietet sowohl Sicherheits- als auch Feature-Verbesserungen gegenüber SSH-1. Bessere Sicherheit zum Beispiel kommt durch Diffie -Hellman Key Exchange und stark Integrität Überprüfung über Nachrichtenauthentifizierungscodes. Zu den neuen Funktionen von SSH-2 gehören die Möglichkeit, eine beliebige Anzahl von Ausführungen auszuführen Hülse Sitzungen über eine einzelne SSH -Verbindung.^[17] Aufgrund der Überlegenheit und Beliebtheit von SSH-2 gegenüber SSH-1 einige Implementierungen wie LibSSH (v0.8.0+),^[18] LSH^[19] und DropBear^[20] Unterstützen Sie nur das SSH-2-Protokoll.

Version 1.99

Im Januar 2006, weit nach der Gründung von Version 2.1, RFC 4253 Es gab an, dass ein SSH -Server, der 2.0 sowie frühere Versionen unterstützt, seine Protokollversion als 1,99 identifizieren sollte.^[21] Diese Versionsnummer spiegelt keine historische Software -Revision wider, sondern eine Methode zum Identifizieren Rückwärtskompatibilität.

OpenSSH und OSSH

Im Jahr 1999 startete Entwickler, die die Verfügbarkeit einer kostenlosen Softwareversion wünschte, die Softwareentwicklung aus der Veröffentlichung des Original -SSH -Programms 1.2.12, das zuletzt unter einem veröffentlicht wurde Open Source -Lizenz. Dies diente als Codebasis für die OSSH -Software von Björn Grönvall. Kurz danach, OpenBSD Entwickler gegabelt Grönvalls Code und erstellt OpenSSH, die mit Release 2.6 von OpenBSD geliefert wurde. Aus dieser Version wurde eine "Portabilität" -Ag -Filiale zum Port OpenSH zu anderen Betriebssystemen gebildet.^[22]

Ab 2005^{[aktualisieren]}, OpenSSH war die beliebteste SSH -Implementierung, die die Standardversion in einer großen Anzahl von Betriebssystemverteilungen war. Ossh ist inzwischen veraltet geworden.^[23] OpenSSH wird weiterhin gepflegt und unterstützt das SSH-2-Protokoll, da die SSH-1-Unterstützung durch die Codebasis in der OpenSSH 7.6-Version ausgedehnt wird.

Verwendet

Beispiel für das Tunneln eines X11 Anwendung über SSH: Der Benutzer 'Josh' hat "Sshed" vom lokalen Maschinenfoofighter zum Remote -Maschine 'Tengwar', um zu laufen Xeyes.

Anmeldung in OpenWrt über SSH verwendet Kitt Laufen Fenster.

SSH ist ein Protokoll, das für viele Anwendungen auf vielen Plattformen, einschließlich der meisten, verwendet werden kann Unix Varianten (Linux, das BSDS einschließlich Äpfel Mac OS, und Solaris), ebenso gut wie Microsoft Windows. Einige der folgenden Anwendungen erfordern möglicherweise Funktionen, die nur mit bestimmten SSH -Clients oder Servern verfügbar oder kompatibel sind. Beispielsweise verwenden Sie das SSH -Protokoll zur Implementierung a VPN ist möglich, aber derzeit nur mit dem OpenSSH Server- und Client -Implementierung.

• Zum Login bei einer Shell auf einem Remote -Host (Austausch Telnet und Rlogin)
• Für die Ausführung eines einzelnen Befehls auf einem Remote -Host (Austausch rsh)
• Zum Einrichten der automatischen (kennwortlosen) Anmeldung bei einem Remote -Server (zum Beispiel mit Verwendung OpenSSH^[24])
• In Kombination mit rsync Zum Sichern, kopieren und spiegeln Sie Dateien effizient und sicher
• Zum Weiterleitung ein Port
• Zum Tunneling (Nicht zu verwechseln mit a VPN, die Routen Pakete zwischen verschiedenen Netzwerken oder Brücken zwei Sendungsdomänen in eins).
• Für die Verwendung als vollwertiger verschlüsselter VPN. Beachten Sie nur das OpenSSH Server und Client unterstützt diese Funktion.
• Zum Weiterleiten X von einer Fernbedienung Gastgeber (möglich durch mehrere Zwischenwirte)
• Zum Durchsuchen des Webs durch eine verschlüsselte Proxy -Verbindung mit SSH -Clients, die die unterstützen Sockenprotokoll.
• Für die sichere Montage eines Verzeichnisses auf einem Remote -Server als Dateisystem auf einem lokalen Computer verwenden Sshfs.
• Für die automatisierte Fernüberwachung und -verwaltung von Servern über einen oder mehrere der oben diskutierten Mechanismen.
• Für die Entwicklung eines mobilen oder eingebetteten Geräts, das SSH unterstützt.
• Zur Sicherung von Dateiübertragungsprotokollen.

Dateiübertragungsprotokolle

Die sicheren Shell -Protokolle werden in mehreren Dateiübertragungsmechanismen verwendet.

• Sichere Kopie (SCP), das sich aus entwickelte RCP Protokoll über SSH
• rsync, beabsichtigt, effizienter als SCP zu sein. Im Allgemeinen läuft über eine SSH -Verbindung.
• SSH -Dateiübertragungsprotokoll (SFTP), eine sichere Alternative zu Ftp (nicht zu verwechseln mit FTP über SSH oder Ftps)
• Dateien, die über das Shell -Protokoll übertragen wurden (a.k.a. fish), veröffentlicht 1998, das sich aus entwickelte Unix Shell Befehle über SSH
• Schnelles und sicheres Protokoll (Fasp), auch bekannt als Aspera, verwendet SSH für Steuer- und UDP -Ports für die Datenübertragung.

Die Architektur

Diagramm des SSH-2-Binärpakets.

Das SSH -Protokoll verfügt über eine geschichtete Architektur mit drei separaten Komponenten:

• Das Transportschicht ( RFC 4253) verwendet normalerweise die Transmissionskontrollprotokoll (TCP) von TCP/IP, reservieren Port-Nummer 22 als Server -Höranschluss. Diese Ebene behandelt den ersten Schlüsselaustausch sowie die Serverauthentifizierung und legt Verschlüsselung, Komprimierung und Integritätsüberprüfung ein. Es wird der oberen Ebene eine Schnittstelle zum Senden und Empfangen von Klartextpaketen mit einer Größe von jeweils 32.768 Bytes ausgesetzt, aber durch jede Implementierung können jedoch mehr zulässig sein. Die Transportschicht arrangiert auch die wichtige Wiederausstimmung, normalerweise nach Übertragen von 1 GB Daten oder nach einer Stunde, je nachdem, was zuerst eintritt.
• Das Benutzerauthentifizierungsschicht ( RFC 4252) behandelt die Client -Authentifizierung und bietet eine Reihe von Authentifizierungsalgorithmen. Authentifizierung ist kundenorientiert: Wenn man für ein Passwort aufgefordert wird, kann es sich um den SSH -Client handeln, nicht der Server. Der Server reagiert lediglich auf die Authentifizierungsanfragen des Kunden. Die weit verbreiteten Methoden der Benutzerauthentifizierung umfassen die folgenden:
  • Passwort: Eine Methode zur einfachen Authentifizierung von Kennwort, einschließlich einer Einrichtung, mit der ein Kennwort geändert werden kann. Nicht alle Programme implementieren diese Methode.
  • Öffentlicher Schlüssel: Eine Methode für Authentifizierung auf öffentlich-key-basierte Authentifizierung, normalerweise zumindest unterstützen DSA, ECDSA oder RSA Tastaturen mit anderen Implementierungen auch unterstützend X.509 Zertifikate.
  • Tastaturinteraktiv ( RFC 4256): Eine vielseitige Methode, bei der der Server eine oder mehrere Eingabeaufforderungen zum Eingeben von Informationen sendet, und der Client zeigt diese an und sendet die vom Benutzer ausschließlichen Antworten zurück. Verwendet, um bereitzustellen einmaliges Passwort Authentifizierung wie S/Schlüssel oder Securid. Wird von einigen OpenSSH -Konfigurationen verwendet, wenn Pam ist der zugrunde liegende Anbieter von Host-Authentifizierungen, um die Kennwortauthentifizierung effektiv bereitzustellen, was manchmal zu einer Unfähigkeit führt, sich mit einem Client anzumelden, der nur die Ebene unterstützt Passwort Authentifizierungsmethode.
  • GSSAPI Authentifizierungsmethoden, die ein erweiterbares Schema zur Durchführung von SSH -Authentifizierung unter Verwendung externer Mechanismen bieten, wie z. Kerberos 5 oder NtlmBereitstellung Einmalige Anmeldung Fähigkeit zu SSH -Sitzungen. Diese Methoden werden in der Regel von kommerziellen SSH -Implementierungen für die Verwendung in Organisationen implementiert, obwohl OpenSSH über eine funktionierende GSSAPI -Implementierung verfügt.
• Das Verbindungsschicht ( RFC 4254) definiert das Konzept von Kanälen, Kanalanfragen und globalen Anfragen, die die bereitgestellten SSH -Dienste definieren. Eine einzelne SSH -Verbindung kann gleichzeitig in mehrere logische Kanäle multiplexiert werden, wobei jeder Daten bidirektional überträgt. Kanalanfragen werden verwendet, um kanalspezifische Daten außerhalb des Bandes zu veröffentlichen, z. Zusätzlich führt jeder Kanal unter Verwendung der Empfangsfenstergröße eine eigene Flusssteuerung durch. Der SSH-Client fordert einen serverseitigen Port an, der mit einer globalen Anforderung weitergegeben werden soll. Standardkanaltypen umfassen:
  • Hülse Für Terminalschalen, SFTP- und EXEC -Anforderungen (einschließlich SCP -Transfers)
  • Direct-TCPIP Für Client-to-Server-weitergeleitete Verbindungen
  • weitergeleitet-tcpip Für Server-to-Client-weitergeleitete Verbindungen
• Das SSHFP DNS -Rekord (RFC 4255) stellt die öffentlichen Host -Schlüsselfingerabdrücke zur Verfügung, um die Authentizität des Gastgebers zu überprüfen.

Diese offene Architektur bietet erhebliche Flexibilität und ermöglicht die Verwendung von SSH für eine Vielzahl von Zwecken über eine sichere Hülle hinaus. Die Funktionalität der Transportschicht allein ist vergleichbar mit Transportschichtsicherheit (TLS); Die Benutzer-Authentifizierungsschicht ist mit benutzerdefinierten Authentifizierungsmethoden hoch erweiterbar. und die Verbindungsschicht bietet die Möglichkeit, viele Sekundärsitzungen in eine einzelne SSH -Verbindung zu multiplexen, eine Funktion, die vergleichbar ist SIGNALTON und nicht in TLS verfügbar.

Algorithmen

• EDDSA,^[25] ECDSA, RSA und DSA zum Kryptographie der Öffentlichkeit.^[26]
• Ecdh und Diffie -Hellman zum Schlüsselaustausch.^[26]
• HMAC, Aead und Umac zum MAC.^[27]
• AES (und veraltet RC4, 3des, Des^[28]) zum Symmetrische Verschlüsselung.
• AES-GCM^[29] und Chacha20-Poly1305 zum Aead Verschlüsselung.
• Sha (und veraltet MD5) zum Schlüsselfingerabdruck.

Schwachstellen

SSH-1

Im Jahr 1998 wurde eine Schwachstelle in SSH 1.5 beschrieben, was das nicht autorisierte Insertion von Inhalten in einen verschlüsselten SSH -Stream aufgrund unzureichender Datenintegritätsschutz vor Ort ermöglichte CRC-32 verwendet in dieser Version des Protokolls.^[30][31] Ein Fix, der als SSH -Kompensationsangriffsdetektor bekannt ist^[32] wurde in die meisten Implementierungen eingeführt. Viele dieser aktualisierten Implementierungen enthielten eine neue Ganzzahlüberlauf Verletzlichkeit^[33] Dies ermöglichte es den Angreifern, willkürlichen Code mit den Berechtigungen des SSH -Daemons auszuführen, typischerweise Root.

Im Januar 2001 wurde eine Sicherheitsanfälligkeit entdeckt, die es den Angreifern ermöglicht, den letzten Block eines IDEE-Crypted Session.^[34] Im selben Monat wurde eine weitere Sicherheitsanfälligkeit entdeckt, die es einem böswilligen Server ermöglichte, eine Client -Authentifizierung an einen anderen Server weiterzuleiten.^[35]

Da SSH-1 inhärente Designfehler aufweist, die es anfällig machen, wird es jetzt allgemein als veraltet angesehen und sollte vermieden werden, indem der Fallback bei SSH-1 explizit deaktiviert wird.^[35] Die meisten modernen Server und Kunden unterstützen SSH-2.^[36]

CBC Plaintext Recovery

Im November 2008 wurde für alle Versionen von SSH eine theoretische Sicherheitsanfälligkeit entdeckt, die eine Wiederherstellung von bis zu 32 Bit Klartext von einem Chiffrettext ermöglichten, der mit dem damaligen Standardverschlüsselungsmodus verschlüsselt wurde. CBC.^[37] Die unkomplizierteste Lösung ist die Verwendung Ctr, Gegenmodus anstelle des CBC -Modus, da dies SSH gegen den Angriff resistent macht.^[37]

Verdächtige Entschlüsselung durch NSA

Am 28. Dezember 2014 Der Spiegel Veröffentlichte klassifizierte Informationen^[38] durch Whistleblower durchgesickert Edward Snowden was deutet darauf hin, dass die Nationale Sicherheitsbehörde Möglicherweise kann man einen SSH -Verkehr entschlüsseln. Die technischen Details, die mit einem solchen Prozess verbunden sind, wurden nicht bekannt gegeben. Eine Analyse von 2017 der CIA Hacking -Tools Bothanspy und Gyrfalcon schlug vor, dass das SSH -Protokoll nicht beeinträchtigt wurde.^[39]

Standarddokumentation

Folgende RFC Veröffentlichungen von der Ietf "Secsh" Arbeitsgruppe Dokument SSH-2 als vorgeschlagen Internetstandard.

• RFC 4250 – Das SSH -Protokoll (Secure Shell) zugewiesene Zahlen
• RFC 4251 – Die Secure Shell (SSH) -Protokollarchitektur
• RFC 4252 – Das SSH -Authentifizierungsprotokoll (Secure Shell)
• RFC 4253 – Das SSH -Transportschichtprotokoll (SSH)
• RFC 4254 – Das SSH -Verbindungsprotokoll (Secure Shell)
• RFC 4255 – Verwenden von DNS, um sicher
• RFC 4256 – Generische Nachrichtenaustauschauthentifizierung für das Secure Shell Protocol (SSH)
• RFC 4335 – Die Secure Shell (SSH) SSSH -SHSH -Kanal -Break -Erweiterung
• RFC 4344 – Die Secure Shell (SSH) Transportschichtverschlüsselungsmodi
• RFC 4345 – Verbesserte ArcFour -Modi für das SSH -Transportschichtprotokoll (SSH)

Die Protokollspezifikationen wurden später durch die folgenden Veröffentlichungen aktualisiert:

• RFC 4419 – Diffie-Hellman-Gruppenaustausch für das Secure Shell (SSH) Transportschichtprotokoll (März 2006)
• RFC 4432 – RSA -Schlüsselaustausch für das SSH -Transportschichtprotokoll für die sichere Shell (SSH) (März 2006)
• RFC 4462 – GSS-API-Authentifizierung (Generic Security Service Application Program Interface (GSS-API) und Schlüsselaustausch für das SSH-Protokoll (Secure Shell) (Mai 2006)
• RFC 4716 – Das öffentliche Schlüsseldatei -Format für öffentliche Schlüsseln (SSH) (November 2006)
• RFC 4819 – Sichern Sie das Subsystem von Shell Public Key (März 2007)
• RFC 5647 – AES Galois Counter -Modus für das sichere Shell Transport Layer -Protokoll (August 2009)
• RFC 5656 – Integration der elliptischen Kurvenalgorithmus in die sichere Schalentransportschicht (Dezember 2009)
• RFC 6187 – X.509V3 Zertifikate für die sichere Shell -Authentifizierung (März 2011)
• RFC 6239 – SUITE B Kryptografische Suiten für sichere Schale (SSH) (Mai 2011)
• RFC 6594 – Verwendung des SHA-256-Algorithmus mit RSA, digitaler Signaturalgorithmus (DSA) und elliptischer Kurve DSA (ECDSA) in SSHFP-Ressourcensätzen (April 2012)
• RFC 6668 – SHA-2-Datenintegritätsprüfung für das SSH-Transportschichtprotokoll (Secure Shell) (Juli 2012)
• RFC 7479 – Ed25519 SSHFP Resource Records (März 2015)
• RFC 5592 – Sicheres Shell -Transportmodell für das einfache Netzwerkmanagementprotokoll (SNMP) (Juni 2009)
• RFC 6242 – Verwenden des NetConf -Protokolls über sichere Shell (SSH) (Juni 2011)
• RFC 8332 – Verwendung von RSA-Tasten mit SHA-256 und SHA-512 im SSH-Protokoll (Secure Shell) (März 2018)
• Draft-Gerhards-Syslog-transport-ssh-00- SSH -Transportkartierung für Syslog (Juli 2006)
• Draft-ITF-SECSH-FILEXFER-13- SSH -Dateiübertragungsprotokoll (Juli 2006)

zusätzlich OpenSSH Das Projekt beinhaltet mehrere Anbieterprotokollspezifikationen/-ausweiterungen:

• OpenSsh -Protokollübersicht
• OpenSSH -Zertifikat/Schlüsselübersicht
• Draft-Miller-SSH-Agent-04 - SSH Agent Protocol (Dezember 2019)

Siehe auch

• Brute-Force-Angriff
• Vergleich von SSH -Kunden
• Vergleich von SSH -Servern
• Korkenzieher
• Identität
• OpenSSH
• Sichern Sie den Schalen -Tunneling
• Webbasierte SSH

Verweise

Weitere Lektüre

• Barrett, Daniel J.; Silverman, Richard E.; Byrnes, Robert G. (2005). SSH: Die sichere Schale (die endgültige Anleitung) (2. Aufl.). O'Reilly. ISBN 0-596-00895-3.
• Stahnke, Michael (2005). Pro OpenSsh. Apress. ISBN 1-59059-476-2.
• Tatu Ylönen (12. Juli 1995). "Ankündigung: SSH (Secure Shell) Remote -Login -Programm". Comp.Security.unix. Ursprüngliche Ankündigung von SSH
• Dwivedi, Himanshu (2003). Implementierung von SSH. Wiley. ISBN 978-0-471-45880-7.

Externe Links

• SSH -Protokolle
• M. Joseph; J. Susoy (November 2013). P6Rs Secure Shell Public Key Subsystem. doi:10.17487/rfc7076. RFC 7076.