Secure Shell: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
 
(101 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
= Was ist die Secure Shell? =
'''Secure Shell''' ('''SSH''') - [[Kryptografie|kryptographisches]] [[Netzwerkprotokoll]] für den sicheren Betrieb von [[Netzwerkdienst]]en über ungesicherte Netzwerke
* Es gab einmal eine Zeit, als Computer im Netz über das [http://de.wikipedia.org/wiki/Telnet Telnet]-Protokoll zugänglich waren. Da dieses Protokoll keine Verschlüsselung bot, wurde das Mitschneiden von Passwörtern zur trivialen Angelegenheit.
* Um den Fernzugang zu sichern, schrieb Tatu Ylönen Mitte der 1990er eine Programmsuite – bestehend aus Server, Client und Hilfsprogrammen – die er '''ssh''' (''secure shell'') nannte.
* Später gründete er die Firma [http://www.ssh.com/ ssh.com] und bot die Version 2 der SSH-Suite nur noch kommerziell an. Daraufhin wurde von Entwicklern des Betriebssystems [http://de.wikipedia.org/wiki/OpenBSD OpenBSD] der öffentliche Quellcode der Version 1 [http://de.wikipedia.org/wiki/Abspaltung_%28Softwareentwicklung%29 geforkt]. Sie entwickelten das Programm unter dem Namen "OpenSSH" weiter. Diese OpenSSH-Suite wurde fester Bestandteil quasi aller Linux-Distributionen.
* Drei wichtige Eigenschaften führten zum Erfolg von '''ssh''' :* Authentifizierung der Gegenstelle, kein Ansprechen falscher Ziele
** Verschlüsselung der Datenübertragung, kein Mithören durch Unbefugte
** Datenintegrität, keine Manipulation der übertragenen Daten
* Mehr Details zur verwendeten Verschlüsselung finden sich [https://wiki.ubuntuusers.de/SSH/#Weitere-Verschluesselungsdetails weiter unten]. Falls man sich auf den eigenen Computer hinter einem DSL-Router per SSH einloggen will, muss man zuvor in diesem eine [https://wiki.ubuntuusers.de/Portweiterleitung/ Portweiterleitung] einrichten, sonst kommt keine Verbindung zustande.


= Der SSH-Client =
== Beschreibung ==
* Das funktioniert normalerweise in einen Terminal-Fenster [https://wiki.ubuntuusers.de/SSH/#source-2 [2]] so:
; Verwendung
ssh user@sol-1
* Fernzugriff auf Computersysteme
user@sol-1's password:
* Sichere Übertragung von Dateien über nicht vertrauenswürdige Netzwerke
Last login: Sun Feb 12 07:38:50 2006 from client.local
* Entfernte [[Kommandozeile]]
Sun Microsystems Inc.  SunOS 5.9      Generic_112234-03      November 2002
** auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben
bash-2.05$
** lokale Tastatureingaben werden an den entfernten Rechner gesendet
Und schon befindet man sich auf einem anderen System, in diesem Fall mit dem Betriebssystem Solaris.
ssh server
Password:
Linux vdr 2.4.27-ctvdr-1 #1 Fri Oct 15 18:38:29 UTC 2004 i686 GNU/Linux
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
You have new mail.
Last login: Sun Feb 12 07:38:23 2006 from client.local
user@server:~$
Oder auf einem anderen Linux-System. Wie man sieht, ist die Angabe des Benutzernamens optional, wenn er auf beiden Systemen gleich ist. Man kann auch einfach einen Befehl anhängen, der anstelle der Terminal-Session ausgeführt wird. Nach der Ausführung des Befehls wird die SSH-Session dann automatisch beendet:
ssh server cat /etc/issue
Password:
Debian GNU/Linux 3.1 \n \l


Oder etwas komplizierter - eine Datensicherung machen ("backup"):
; Verfügbarkeit
user@client:~$ ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz
* [[Unixoides System|unixoiden]] Betriebssysteme
Password:
* [[Microsoft Windows]]
network/
network/interfaces
network/if-post-down.d/
network/if-pre-up.d/
network/if-up.d/
network/if-down.d/
network/options
network/interfaces.pre-etherconf
network/interfaces.1
network/run
Bei einer langsamen Verbindung empfiehlt sich zusätzlich die Benutzung der Option <tt>-C</tt> (großes C), die zusätzlich zur Verschlüsselung eine transparente Kompression der übertragenen Daten aktiviert. Bei einer schnellen Verbindung wird die Kompression aber vermutlich bremsen.
* Woher weiß man nun aber, dass man tatsächlich mit dem richtigen Rechner verbunden ist, und nicht ein Angreifer die Verbindung umgeleitet hat? Dafür gibt es den Host-Schlüssel, der jeden SSH-Server eindeutig identifiziert. Greift man zum ersten Mal auf einen bestimmten Server zu, kennt man diesen Schlüssel natürlich noch nicht. (Außer man hat ihn sich auf anderen Wegen im Voraus besorgt.)
ssh server
The authenticity of host 'server (192.168.1.5)' can't be established.
ECDSA key fingerprint is b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server' (ECDSA) to the list of known hosts.
Password:
* Wenn gerade in diesem Moment jemand die Verbindung gekapert hat, hat man natürlich Pech, außer man kann den Administrator des Servers nach dem richtigen Fingerprint des Host-Schlüssels fragen.
* Den ECDSA-Fingerprint eines Servers kann man mit dem Systemprogramm '''ssh-keygen''' erfahren:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
gibt den Fingerprint und einige weitere Informationen aus, z.B. <tt>256 b5:0e:ec:b7:16:06:e6:24:a6:39:18:58:4e:ec:3b:d1 root@server (ECDSA)</tt>. Wenn man auf Nummer sicher gehen möchte, lässt man sich vom Administrator des Servers diese Ausgabe mitgeben (evtl. ausdrucken) und kann dann beim ersten Verbindungsversuch überprüfen, ob man sich tatsächlich zum richtigen SSH-Server verbunden hat und nicht zu einem dazwischengeschalteten Angreifer.


Bei allen weiteren Kontakten stellt das '''ssh'''-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen öffentlichen Schlüssel verfügt, der zum öffentlichen, in der Datei '''~/.ssh/known_hosts''' abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau.
; Ziele
Authentifizierung
* Authentifizierung der Gegenstelle
* Kein Ansprechen falscher Ziele
Vertraulichkeit
* Kryptografie der Datenübertragung
Integrität
* Keine Manipulation der übertragenen Daten


Sollte sich dieser Schlüssel einmal aus legitimen Gründen geändert haben, bspw. weil das System neu aufgesetzt wurde, muss man den entsprechenden veralteten Schlüssel erst einmal auf dem Client mit dem Befehl
; Port Zuordnung
* [[Internet Assigned Numbers Authority|IANA]]
* [[Transmission Control Protocol|TCP]]-[[Port (Protokoll)|Port]] 22
* [[User Datagram Protocol|UDP]]-Port 22
* [[Stream Control Transmission Protocol|SCTP]]-Port 22


ssh-keygen -R hostname
; [[Client-Server-Modell|Client–Server]]-Architektur
Eine SSH-Client-Anwendung verbindet sich mit einem SSH-Server
;Protokollspezifikation
* SSH-1
* SSH-2


aus der '''known_hosts'''-Datei entfernen.
; Fernwartung
* Genutzt werden kann dies z.&nbsp;B.&nbsp; zur [[Fernwartung]] eines in einem entfernten Rechenzentrum stehenden [[Server]]s.
* Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie [[Datenübertragung]] per [[SSH File Transfer Protocol|SFTP]].


Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der ssh-Client mit der Eingabe von "<tt>~.</tt>" (nacheinander) beenden.
Ersatz für Telnet
* Bestandteil aller Linux- und Unix-Distributionen
* Dabei dient SSH als Ersatz für andere, unsichere Methoden wie [[Telnet]].
* Bei diesen werden alle Informationen, auch sensible wie etwa [[Passwort|Passwörter]], im [[Klartext (Kryptografie)|Klartext]] übertragen.
* Dies macht sie anfällig für [[Man-in-the-Middle-Angriff]]e sowie einen Vertraulichkeitsverlust durch [[Sniffer|Packet Analyzer]], die die [[Datenpaket]]e mitschneiden. Die [[Kryptografie]]stechnik, die durch SSH genutzt wird, hat deshalb den Zweck, die Vertraulichkeit, Integrität und Authentizität von Daten, die über ein unsicheres Netzwerk (wie z.&nbsp;B.&nbsp; das [[Internet]]) gesendet werden, sicherzustellen.


== Hinweis ==
== Siehe auch ==
Wer (noch) einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm [https://wiki.ubuntuusers.de/PuTTY/ PuTTY] nutzen.
* [[OpenSSH]]
 
{{Special:PrefixIndex/SSH}}
= Benutzeroberflächen =
 
Wem es zu mühsam ist, auf der Kommandozeile die SSH-Verbindung zu einem Server aufzubauen, der sucht vielleicht ein grafisches Programm, um Verbindungsdaten zu verwalten.* [https://wiki.ubuntuusers.de/PuTTY/ PuTTY] - gibt es sowohl für Linux als auch für Windows. Das Programm ist in den offiziellen Paketquellen enthalten.
* [http://sourceforge.net/projects/pacmanager PAC Manager] - ('''Perl''' '''A'''uto '''C'''onnector) nicht in den offiziellen Paketquellen enthalten, aber über SourceForge wird ein Fremdpaket angeboten, das manuell installiert werden kann.
* [http://sourceforge.net/projects/gnome-rdp Gnome-RDP] - mit diesem Programm kann man nicht nur [http://de.wikipedia.org/wiki/Remote_Desktop_Protocol RDP]- und [https://wiki.ubuntuusers.de/VNC/ VNC]-Verbindungen aufbauen, sondern auch SSH-Terminalsitzungen. Leider kann man in der aktuellen Version die Zugangspasswörter nicht speichern lassen und keine Angaben zum verwendeten Port machen. Es funktioniert somit nur mit Servern, die den Standard-SSH-Port <tt>22</tt> nutzen. In den offiziellen Paketquellen enthalten, benötigt aber [http://de.wikipedia.org/wiki/Mono-Projekt Mono] als Voraussetzung.
 
== .ssh/config ==
 
Wenn man sich auf der Konsole mit einem anderen Server verbinden möchte, muss man evtl. z.B. Port und Benutzernamen angeben. Um das Ganze zu vereinfachen, kann man Voreinstellungen für ssh in der config-Datei '''$HOME/.ssh/config''' hinterlegen. Hier ein Beispiel:
 
# '''ssh (secure shell) configuration file'''
Host test1
    HostName 123.456.789.0
    Port 980
    User MeinBenutzerName
Host test2
    HostName test.mynet.local
    User test
    CheckHostIP no
    Cipher blowfish
Host foobar
    HostName domain.tld
    Port 55550
    User fanta
    IdentityFile ~/.ssh/private_ssh_key_rsa
 
ssh MeinBenutzerName@123.456.789.0 -p980
 
ssh test1
 
für einen Verbindungsaufbau. Alle Parameter, die man verwenden kann, findet man unter [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config openbsd.org] oder in der [https://wiki.ubuntuusers.de/man/ Manpages] von '''ssh_config'''.
 
= SSH-Server =
Im Gegensatz zum SSH-Klienten ist der SSH-Server unter Ubuntu standardmäßig nicht installiert.  #apt-get install openssh-server
 
installieren [https://wiki.ubuntuusers.de/SSH/#source-1 [1]].
 
Die Konfiguration des SSH-Servers '''sshd''' findet über die Datei '''/etc/ssh/sshd_config''' statt. Die Voreinstellungen sind aber durchweg akzeptabel.
 
Wer den '''sshd''' auf einem Gateway oder Router betreibt oder aus einem anderen Grund mehrere Netzwerkschnittstellen verwendet (bspw. WLAN), der möchte dort vielleicht die '''ListenAddress'''-Direktive benutzen, um den Server nur an bestimmten Netzwerk-Schnittstellen laufen zu lassen.
 
Außerdem kann es sinnvoll sein, '''PermitRootLogin''' auf '''no''' zu setzen. Dann kann sich niemand direkt als ''root'' einloggen, sondern man meldet sich unter seinem Benutzernamen an und ruft dann '''su''' oder '''sudo -s''' auf. Dies ist aber unter Ubuntu nur relevant, sollte man dem "root"-Benutzerkonto ein Passwort zugewiesen haben.
 
Mit den Direktiven '''AllowUsers''' und '''AllowGroups''' bzw. '''DenyUsers''' und '''DenyGroups''' lässt sich noch genauer festlegen, welche Benutzer sich anmelden dürfen und welche nicht. Dies empfiehlt sich besonders bei Servern. '''AllowGroups admin''' verbietet bspw. allen Benutzern, die keine Mitglieder der Gruppe ''admin'' sind, den Zugriff.
 
Wer sich ausschließlich über das noch sicherere [https://wiki.ubuntuusers.de/SSH/#Authentifizierung-ueber-Public-Keys Public-Key-Verfahren] anmelden will, der sollte die Benutzung von Passwörtern mit '''PasswordAuthentication no''' abschalten.
 
Falls lange Wartezeiten bei der Anmeldung am SSH-Server auftreten, könnte das an einer fehlgeschlagenen Namensauflösung liegen. Da man SSH normalerweise sowieso über die IP benutzt, können diese DNS-Anfragen in der '''sshd_config''' deaktiviert werden. Der dafür nötige Eintrag wäre '''UseDNS no'''.
 
Nach erfolgter Änderung der Datei '''sshd_config''' muss der Server mit dem Befehl:
 
sudo reload ssh
 
neugestartet werden, damit die Änderungen wirksam werden.
 
'''Hinweis'''
 
Standardmäßig wird der SSH-Server beim Booten geladen. Ab [https://wiki.ubuntuusers.de/Lucid_Lynx/ Ubuntu 10.04] ist Upstart für den Autostart des SSH-Servers zuständig. Wie man den Autostart deaktiviert, wird im [https://wiki.ubuntuusers.de/Upstart/#Deaktivieren-von-Init-Jobs Upstart-Artikel] beschrieben.
 
== Dateitransfer ==
 
Wenn man also ein Protokoll hat, das so sicher wie nach dem heutigen Stand der Technik möglich Daten durch einen verschlüsselten Kanal senden und empfangen kann, dann wäre es wohl Verschwendung, dieses Protokoll nur für interaktive Terminal-Sessions zu benutzen. Sehr häufig möchte man bspw. einfach nur Dateien sicher von einem System zum anderen bewegen. Dafür existieren verschiedene Programme der grafischen Benutzeroberfläche sowie gleich zwei Terminalbefehle nämlich '''scp''' und '''sftp'''.
 
=== Transfer von der Kommandozeile ===
 
==== scp ====
 
Das Kommandozeilenwerkzeug '''scp''' funktioniert in etwa so wie das normale Unix-Kommando '''cp''', nur dass es über Systemgrenzen hinweg funktioniert. Jedes Datei- oder Verzeichnisargument kann dabei optional, getrennt durch einen Doppelpunkt, durch einen vorangestellten Benutzer- bzw. Hostnamen ergänzt werden. Dabei werden weggelassene Teile durch den aktuellen Benutzernamen, ''localhost'' bzw. das Homeverzeichnis (bzw. das aktuelle Verzeichnis) ergänzt, etwa so:
 
scp benutzerx@server1:datei1 datei2 benutzery@server2:
 
In diesem Beispiel wurde die ''datei1'' aus dem Homeverzeichnis von ''benutzerx'' auf ''server1'' und die ''datei2'' aus dem aktuellen Verzeichnis des lokalen Hosts in das Homeverzeichnis von ''benutzery'' auf ''server2'' kopiert.
 
Der Befehl '''scp''' versteht auch einige von [https://wiki.ubuntuusers.de/cp/ cp] bekannte Optionen, bspw. <tt>-r</tt> für das rekursive Kopieren ganzer Verzeichnisbäume. Bedauerlicherweise unterstützt '''scp''' aber nicht alle '''cp'''-Optionen, die für das exakte Klonen von Verzeichnissen, inkl. aller Dateirechte und symbolischen Verknüpfungen notwendig sind. Für die exakte Replikation sollte deswegen entweder das Werkzeug <tt>rsync -e ssh</tt> genutzt werden (man beachte die Handbuchseite zu diesem Tool) oder der oben schon genutzte Trick mit '''tar''' und einer Pipe.
 
ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf -
 
==== sftp ====
 
Die andere Möglichkeit des Dateitransfers lautet '''sftp'''. Das funktioniert genau so wie der normale Kommandozeilen-FTP-Client:
 
sftp server
 
vergrößern
 
Connecting to server...
user@server's password:
sftp> pwd
Remote working directory: /export/home/user
sftp> dir
[...]
wichtige_datei.txt
[...]
sftp> get wichtige_datei.txt
Fetching /export/home/user/wichtige_datei.txt to wichtige_datei.txt
/export/home/user/wichtige_datei.txt                                                    100%  62KB  62.2KB/s  00:00
sftp> quit
 
Mit dem Befehl '''help''' bekommt man eine Übersicht über die möglichen Kommandos.
 
=== Entfernte Dateisysteme einbinden ===
 
Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels [https://wiki.ubuntuusers.de/FUSE/sshfs/ sshfs] einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.
 
=== Grafische Programme zum Dateitransfer ===
 
==== Gnome/Ubuntu ====
 
Der Gnome-Dateimanager [https://wiki.ubuntuusers.de/Nautilus/ Nautilus] unterstützt das SSH-Protokoll von Haus aus. Dazu benutzt man eine Adresse der Form <tt>ssh://rechnername/pfad</tt>, um über SSH die Dateien auf dem angegebenen Rechner zu sehen. Wenn man sich als ein anderer Benutzer anmelden möchte, verwendet man stattdessen eine Adresse der Form <tt>ssh://andererbenutzer@rechnername/pfad</tt>. Alternativ können auch die Hosts aus der <tt>~/.ssh/config</tt> verwendet werden. Dort lassen sich auch noch andere SSH-Einstellung, wie. z.B SSH-Keys, definieren. Der Zugriff erfolgt mit <tt>ssh://hostname</tt>. Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen.
 
==== KDE/Kubuntu ====
 
Auch bei KDE ist SSH-Unterstützung eingebaut: Mit einer Adresse der Form '''fish://rechnername/pfad''' kann man auf die Dateien auf einem anderen Rechner zugreifen, und mit''' fish://andererbenutzer@rechnername/pfad''' meldet man sich als anderer Benutzer auf dem Zielrechner an. Dies funktioniert im [https://wiki.ubuntuusers.de/Konqueror/ Konqueror] sowie in allen KDE-Anwendungen.
 
Man kann also beispielsweise im Malprogramm [https://wiki.ubuntuusers.de/KolourPaint/ KolourPaint] via ''Datei'' -> ''Öffnen..'' und dann oben in der Adresszeile eine ''fish://''-Adresse eingeben, um direkt ein Bild auf einem anderen Rechner anzusehen oder zu bearbeiten. Im Dateimanager [https://wiki.ubuntuusers.de/Dolphin/ Dolphin] (Kubuntu-Standard) können über das Bookmark "Netzwerk" und den Assistenten "Netzwerkordner hinzufügen" neue ssh-basierte Netzwerkordner als feste Bookmarks erstellt werden.
 
Wenn der Zielrechner ebenfalls ein UTF-8 codiertes Dateisystem hat, sind u.U. die Umlaute falsch angezeigt. Um dies zu ändern, muss man im Konqueror eine fish-Adresse aufrufen und kann nun unter ''"Extras -> Entfernte Zeichencodierung wählen..."'' die entsprechende Codierung einstellen. Diese Einstellung ist fortan auch in Dolphin gültig. Diese Option einzustellen wird in KDE4 vermutlich in Dolphin selbst möglich sein.
 
==== Xfce/Xubuntu ====
 
Der Xfce-Dateimanager [https://wiki.ubuntuusers.de/Thunar/ Thunar] unterstützt das SSH-Protokoll wie Nautilus unter GNOME. Siehe [https://wiki.ubuntuusers.de/SSH/#Gnome-Ubuntu Gnome-Ubuntu].
 
==== Weitere grafische Programme ====
 
Die meisten grafischen FTP-Clients ([https://wiki.ubuntuusers.de/FTP/ FTP]) unterstützen auch sftp oder scp über das SSH-Protokoll. Beim Gnome FTP-Cient [https://wiki.ubuntuusers.de/gFTP/ gFTP] etwa muss man unter ''"FTP -> Optionen -> Netz -> Voreingestelltes Protokoll"'' in der Drop-Down-Liste '''SSH2''' an Stelle von '''FTP''' auswählen. Leider hat '''gftp''' Probleme, wenn man neben Passwörtern auch ''Public-Keys'' (siehe [https://wiki.ubuntuusers.de/SSH/#Authentifizierung-ueber-Public-Keys Public-Key-Verfahren]) benutzt. Das funktioniert nur mit dem SSH-Agenten (ebenfalls weiter unten beschrieben) und der Einstellung "Benötige SSH Benutzername/Passwort nicht" in ''"FTP -> Optionen -> SSH"''.
 
SSH-Verbindungen zu Datenverzeichnissen auf Fremdrechnern unterstützen auch Datensynchronisationsprogramme wie [https://wiki.ubuntuusers.de/Unison/ Unison] und Backupprogramme wie Keep.
 
== Authentifizierung über Public-Keys ==
 
Wem die Authentifizierung über Passwörter trotz der Verschlüsselung zu unsicher ist, - immerhin könnte das Passwort ja erraten werden - der benutzt am besten das Public-Key-Verfahren. Hierbei wird asymmetrische Verschlüsselung genutzt, um den Benutzer zu authentifizieren. Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei '''~/.ssh/authorized_keys''' des Zielsystems, der private Schlüssel in einer Datei (meist '''id_rsa''') im Verzeichnis '''~/.ssh''' auf dem lokalen System, wo er zusätzlich von einer "pass phrase" geschützt wird. Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte ''Challenge''. Der Klient verschlüsselt diesen Datenblock mit seinem privaten Schlüssel, (wofür nötigenfalls die Passphrase abgefragt wird,) und wenn der Server diesen Chiffre mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln kann, ist die Identität des Benutzers bestätigt.
 
Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms <tt>ssh-keygen</tt> ein entsprechendes Schlüsselpaar erzeugen:
 
ssh-keygen -t rsa -b 4096
 
vergrößern
 
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
The key's randomart image is:
+--[ RSA 4096]----+
|                |
|                |
|                |
|        +    .  |
|        S    E  |
|        .  + +  |
|          .o . o.|
|        o.oo. oo|
|          <nowiki>==o.BO+|</nowiki>
+-----------------+
 
Der voreingestellte Dateiname ('''id_rsa''') kann einfach mit der Taste ⏎ bestätigt werden, außer man möchte sich ein weiteres Schlüsselpaar erzeugen. Von der Benutzung einer leeren Passphrase ist jedoch abzuraten, weil sonst jeder, der evtl. in den Besitz dieser Datei kommt, sofortigen Zugriff auf alle zugehörigen Systeme erhält.
 
Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung ''.pub'' ('''id_rsa.pub'''), auf dem Zielsystem deponiert werden. Dazu dient das Programm '''ssh-copy-id'''. Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein ('''PasswordAuthentication yes'''):
 
ssh-copy-id -i ~/.ssh/id_rsa.pub user@server
Password:
Now try logging into the machine, with "ssh 'user@server'", and check in:
  .ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
 
'''Hinweis'''
 
Sollte man - warum auch immer - bei der Angabe des Dateinamens des Schlüssels die Endung '''.pub''' vergessen, so wird diese automatisch durch <tt>ssh-copy-id</tt> angehängt. Man kann also nie aus Versehen seinen privaten Schlüssel Namens '''id_rsa''' (also ohne Endung '''.pub''') übertragen.
 
Sollte '''ssh-copy-id''' nicht funktionieren, kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei '''~/.ssh/authorized_keys''' einfügen. Dabei ist unbedingt darauf zu achten, dass die Datei mit der Endung '''.pub''' und nicht der private Schlüssel ohne diese Endung verwendet wird:
 
cat id_rsa.pub | ssh server 'cat>> ~/.ssh/authorized_keys'
 
Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption <tt>-i ~/pfad/dateiname</tt> gesondert angegeben werden. Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der [https://wiki.ubuntuusers.de/ssh/#ssh-config ~/.ssh/config] mittels <tt>IdentityFile</tt>-Parameter.
 
'''Hinweis'''
 
Bei [https://wiki.ubuntuusers.de/Precise/ Ubuntu 12.04] sollten die [https://wiki.ubuntuusers.de/Rechte/ Rechte] der Datei '''~/.ssh/authorized_keys''' sowie des Ordners '''~/.ssh''' auf dem Server noch restriktiver gesetzt werden, falls diese neu erzeugt wurden und daher nur mit Standardrechten ausgestattet sind:
 
chmod 700 /home/BENUTZERNAME/.ssh
chmod 600 /home/BENUTZERNAME/.ssh/authorized_keys
 
Anschließend kann man sich ohne Passwort anmelden:
 
ssh user@server
Enter passphrase for key '/home/user/.ssh/id_rsa':
Linux server.local 2.6.12-10-686 #1 Mon Feb 13 12:18:37 UTC 2006 i686 GNU/Linux
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.
Last login: Fri Mar  3 03:51:14 2006
 
In einigen Fällen tritt ein Fehler beim ersten Anmeldeversuch auf:
 
<div style="margin-left:1cm;margin-right:1cm;">''"Agent admitted failure to sign using the key."''</div>
 
In diesem Fall einfach '''ssh-add''' ausführen.
 
ssh-add
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
 
'''Hinweis'''
 
Falls es noch nicht klappt kann es daran liegen, dass die Rechte beim Server nicht korrekt sind. sshd achtet darauf, dass das Homeverzeichnis, das dem Login-Namen entspricht (also die "Mappe" selbst), das <tt>.ssh</tt>-Verzeichnis und <tt>authorized_keys</tt> nur für den Eigentümer Schreibrechte hat. Hintergrund ist wohl, die Gefahr zu verringern, dass <tt>authorized_keys</tt> manipuliert wird und man keinen Zugriff mehr hat, wenn der Passwortzugang (s.u.) gesperrt ist.
 
Wer also bei bestimmten Konten auf dem Server auch einer Gruppe Schreibrechte gewähren will, muss evtl. die Optionen in '''/etc/ssh/sshd_config''' prüfen.
 
Jetzt ist es aber immer noch möglich, sich mit dem Passwort anzumelden. Um dies zu unterbinden, sind in der Datei '''/etc/ssh/sshd_config''' die Optionen
 
PasswordAuthentication no
UsePAM no
 
zu setzen und mit einem
 
sudo /etc/init.d/ssh reload
 
die Konfiguration neu einlesen lassen.
 
Alternativ: Auf der Serverseite eingeben <tt>passwd -l <user></tt>. Damit sind Passwörter nur für ausgewählte Accounts sperrbar.
 
=== Verschlüsseltes Home-Verzeichnis ===
 
Man sollte darauf achten, dass bei verschlüsselten Home-Verzeichnissen (ecryptfs) auch die <tt>authorized_keys</tt> mit verschlüsselt ist und somit nicht zur Authentifizierung verwendet werden kann, solange das Home-Verzeichnis nicht entschlüsselt ist (durch parallele Anmeldung mit dem gleichen Benutzernamen).
 
Eine Abhilfe ist z.B. die <tt>authorized_keys</tt> in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. /etc/ssh/username/) und die Einstellung ''AuthorizedKeysFile'' in der <tt>/etc/ssh/sshd_config</tt> auf ''/etc/ssh/%u/authorized_keys'' zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich).
 
sudo mkdir /etc/ssh/$USER
sudo mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/
ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/
 
Quelle: [http://superuser.com/questions/61057/ssh-with-authorized-keys-to-an-ubuntu-system-with-encrypted-homedir SSH with authorized_keys to an Ubuntu system with encrypted homedir?]  
 
=== Der SSH-Agent ===
 
Unter grafischen Desktop-Sitzungen (Unity, Gnome, etc.) startet automatisch im Hintergrund der SSH-Agent. In diesem werden automatisch die privaten Schlüssel abgelegt, sodass nicht jedes Mal die "pass phrase" abgefragt wird. Dies verbindet die Bequemlichkeit der Bedienung mit der Sicherheit des Public-Key-Verfahrens.
 
Zur direkten Interaktion mit dem SSH-Agenten im Terminal dient das Programm <tt>ssh-add</tt>, wobei die Option <tt>-l</tt> die augenblicklich gespeicherten Schlüssel auflistet:
 
ssh-add -l
{{{
The agent has no identities.
ssh-add
Enter passphrase for /home/user/.ssh/id_rsa:
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)
ssh-add -l
1024 24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 /home/user/.ssh/id_rsa (RSA)
ssh server
Last login: Wed Mar  8 11:11:58 2006 from 192.168.4.56
 
Wenn man nicht über Unity oder eine andere graphische Benutzeroberfläche, die unter dem ssh-agent läuft, eingeloggt ist, funktioniert das so leider nicht. Dann muss man vorher noch ein
 
exec ssh-agent bash
 
ausführen, um eine Shell zu öffnen, die mit dem ssh-agent kommunizieren kann.
 
Arbeitet man oft im Terminal und möchte nicht immer wieder die "pass phrase" eingeben, kann man das folgende in seine '''.bashrc''' eintragen:
 
if [ $SSH_AGENT_PID ]; then
    <nowiki>if [[ $(ssh-add -l) != *id_?sa* ]]; then</nowiki>
        ssh-add -t 2h  <nowiki>## Haltbarkeit von 2 Std.</nowiki>
    fi
fi
 
=== Login über mehrere Rechner ===
 
Ab und zu muss man sich von Rechner zu Rechner hangeln, da kein direkter Zugriff besteht. Doch der Key wird nicht automatisch übertragen. Darum besteht die Möglichkeit dies direkt in der ~/.ssh/config zu vermerken.
 
ForwardAgent yes
 
=== SSH-Askpass ===
 
Wenn eines der Pakete '''ssh-askpass''', '''ssh-askpass-gnome''', '''ssh-askpass-fullscreen''' oder '''gtk-led-askpass''' installiert ist, kann <tt>ssh-add</tt> die Passphrase in Ermangelung eines Terminals auch über ein Dialogfenster abfragen. Das nutzt man sinnvollerweise, um seinen Schlüssel gleich nach der Anmeldung auf einem grafischen System zu laden [https://wiki.ubuntuusers.de/SSH/#source-5 [5]]. Für KDE-Nutzer gibt es das Paket '''ksshaskpass''', das für ssh-add eine graphische Oberfläche zur Verfügung stellt.
 
=== Single-Sign-On ===
 
Wem immer noch zu umständlich ist, beim Login nacheinander erst das Login-Passwort und dann die SSH-Passphrase einzugeben, der installiert sich stattdessen das Paket '''libpam-ssh'''.
 
Mit den richtigen Einstellungen wird man beim Login nach der Eingabe des Benutzernamens nicht mehr nach dem Passwort, sondern nach der SSH-Passphrase gefragt und kann sich danach ohne nervige Passwortabfrage mittels SSH auf seinen Systemen bewegen.
 
Nur wenn man die Passphrase nicht richtig eintippt, kann man sich stattdessen auch mit seinem normalen Passwort authentifizieren. Zu beachten ist allerdings, dass der [https://wiki.ubuntuusers.de/GNOME_Schlüsselbund/ GNOME-Schlüsselbund] dann nicht mehr automatisch freigeschaltet wird.
 
Macht man hier einen Fehler, kann man sich eventuell nicht mehr am System anmelden. Sollte das passiert sein, ist es normalerweise noch möglich, sich per SSH einzuloggen und den Fehler zu beheben. Wenn auch das nicht mehr hilft, muss man das System zum Reparieren im Single-User-[http://de.wikipedia.org/wiki/Runlevel Runlevel] oder von einer Live-CD starten.
 
== X-Forwarding ==
 
Mit dem ''X11-Forwarding'' kann man auch grafische Programme, die man über SSH auf einem anderen Rechner startet, auf dem eigenen Display anzeigen lassen, und zwar unabhängig davon, welches Betriebssystem auf dem entfernten Rechner läuft (siehe Bild.)
 
Das Programm muss sich nur an den X11-Standard halten, was leider die meisten Windows- und Mac-Programme ausschließt.
 
Um das X11-Forwarding zu aktivieren, muss man dem '''ssh'''-Befehl die Option <tt>-X</tt> '''(großes X)''' hinzufügen, die dem Programm eingeschränkte Rechte am eigenen Display einräumt.
 
Für den Fall, dass es zu einem Programmabbruch kommt, weil diese eingeschränkten Rechte nicht ausreichen, existiert noch die Option <tt>-Y</tt>, die dem Programm volle Rechte gewährt.
 
Diese sollte man jedoch nicht verwenden, wenn man dem Administrator des entfernten Rechners nicht vertraut, denn sie öffnet einen Tunnel, der auch in der umgekehrten Richtung für einen Angriff auf das eigene Display genutzt werden könnte.
 
Vorsicht: mit der Option <tt>-x</tt> '''(kleines x)''' wird X11-Forwarding deaktiviert.
 
Hinweis: bei Nutzung von VNC (z.B. für Fernwartung) muss auf dem Server X11VNC installiert sein.
 
Einen deutlichen Geschwindigkeitszuwachs erreicht man durch die Wahl einer anderen Verschlüsselung und der Aktivierung der Kompression der Daten für langsame Verbindungen (DSL, etc.) mit diesen zusätzlichen Optionen im Aufruf von ssh: '''-c arcfour,blowfish-cbc -XC'''. Beispiele:
 
Öffnen des Programms [https://wiki.ubuntuusers.de/Leafpad/ Leafpad]: ssh -X user@server leafpad & Zur bequemeren Nutzung entfernter Programme können auch die Panel-Programme der jeweiligen Desktop-Umgebung gestartet werden, z.B. [https://wiki.ubuntuusers.de/LXDE_Einstellungen/#Panel LXPanel], [https://wiki.ubuntuusers.de/Xfce_Panel/ Xfce Panel] und andere: ssh -X user@server lxpanel &
 
Da Panel-Programme in der Regel nicht über eine Funktion "schließen" verfügen kann man diese z.B. mittels [https://wiki.ubuntuusers.de/xkill/ xkill] schließen.
 
=== Serverkonfiguration ===
 
Dies sollte in der Regel nicht notwendig sein. Auf dem Server muss hierfür das Paket '''xauth '''installiert werden, wenn es das noch nicht ist. Außerdem muss dem SSH-Daemon des Servers mitgeteilt werden, dass X-Forwarding verwendet wird. Das wird über die Konfigurationsdatei '''/etc/ssh/sshd_config''' erledigt. Dort werden die Optionen:
 
X11Forwarding yes
X11UseLocalhost no
 
gesetzt. Danach ist ein Neustart des Daemons erforderlich.
 
Zusätzlich müssen in der Client-Konfigurationsdatei '''/etc/ssh/ssh_config''' die Einträge:
 
ForwardX11 yes
 
und
 
ForwardX11Trusted yes
 
durch Entfernen von <tt><nowiki>#</nowiki></tt> am Zeilenanfang einkommentiert werden.
 
== SSH-Tunnel ==
 
Wenn man mit Hilfe von SSH so ein nicht ganz triviales Protokoll wie X-Window tunneln kann, dann muss das doch auch mit anderen Protokollen funktionieren, oder? - Aber sicher geht das. Allerdings ist die Syntax für den SSH-Tunnelbau ein wenig verwirrend:
 
ssh -L [bind_address:]port:host:port user@server
ssh -R [bind_address:]port:host:port user@server
 
Hierbei richtet die Option <tt>-L</tt> laut Dokumentation eine ''lokale'', und die Option '-R' eine ''entfernte'' (englisch ''remote'') Port-Weiterleitung ein.
 
Der verschlüsselte Tunnel wird dabei '''immer''' zwischen dem eigenen Rechner und ''server'' hergestellt. Die Verbindung vom ''Ende des Tunnels'' zu ''host'' läuft dagegen unverschlüsselt ab, und wird aus Sicht des betreffenden Systems angegeben, weswegen man ''host'' in den allermeisten Fällen wohl auf ''"localhost"'' setzen sollte. Hierbei darf ''"localhost"'' nicht mit dem lokalen Rechner verwechselt werden.
 
Es handelt sich um ''"localhost"'' von ''server'' aus betrachtet, daher um den Server selbst.
 
Die Option <tt>-L</tt> bzw. <tt>-R</tt> gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann. Bei <tt>-L</tt> vom eigenen Rechner zum entfernten hin, bei <tt>-R</tt> in der entgegengesetzten Richtung. (Das merkt man sich am Besten als norma'''L''' und '''R'''ückwärts.)
 
Das erste ''port''-Argument bezeichnet dabei den Einstiegsport in die Verbindung. Zu beachten ist hierbei, dass die Öffnung eines ''privilegierten'' Ports, also unter 1024, nur dem Superuser ''root'' gestattet ist. Man sollte also auf die höheren Ports ausweichen.
 
Mit dem optionalen Parameter ''bind_address'' kann man festlegen, auf welchen Netzwerkschnittstellen die Weiterleitung laufen soll, wobei ''localhost'' der Standard ist.
 
Ein '''<nowiki>*</nowiki>''' oder ein leeres ''bind_address''-Argument vor dem Doppelpunkt bedeutet, dass die Weiterleitung an allen Schnittstellen läuft. Möglicherweise funktioniert das nicht auf jedem Ubuntu-System auf Anhieb, da die IPv6-Adresse das irgendwie verhindert, weshalb man den SSH-Tunnel mit dem Argument '''-4''' auf die IPv4-Schnittstellen beschränken muss.
 
Der zweite ''port''-Parameter gibt schließlich an, auf welchen Port von ''host'' die Weiterleitung gehen soll.
 
Ein weiteres nützliches Argument ist die Option <tt>-N</tt>, die das Erzeugen einer Terminal-Sitzung auf dem entfernten System unterbindet, wenn man nur die Port-Weiterleitung benutzen möchte.
 
=== Beispiele ===
 
Weiterleitung von Port 8000 auf dem lokalen System an den Webserver (Port 80) auf ''server'':
 
ssh -L 8000:localhost:80 server -N &
netstat -anp --inet | egrep '(^Proto|8000)'
Proto Recv-Q Send-Q Local Address          Foreign Address        State      PID/Program name
tcp        0      0 127.0.0.1:8000          0.0.0.0:*              LISTEN    10843/ssh
fg
ssh -L 8000:localhost:80 server -N
[Strg-C]
Killed by signal 2.
 
Dasselbe, aber es wird nicht nur vom lokalen Host weitergeleitet, sondern von allen Schnittstellen (hierzu ist die Option <tt>GatewayPorts</tt> in der Server-Konfiguration entsprechend zu setzen, genaueres zu finden in der Manpage; man wähle diese Option mit Bedacht!):
 
ssh -L *:8000:localhost:80 server -N -4 &
netstat -anp --inet | egrep '(^Proto|8000)'
Proto Recv-Q Send-Q Local Address          Foreign Address        State      PID/Program name
tcp        0      0 0.0.0.0:8000            0.0.0.0:*              LISTEN    10906/ssh
 
Umgekehrte Richtung. Benutzern auf ''server'' wird ermöglicht, über ''localhost:3306'' auf den MySQL-Server auf ''client'' zuzugreifen:
 
ssh -R 3306:localhost:3306 server
Last login: Sat Mar 11 23:24:20 2006 from 192.168.4.56
netstat -an --inet | egrep '(^Proto|3306)'
Proto Recv-Q Send-Q Local Address          Foreign Address        State
tcp        0      0 127.0.0.1:3306          0.0.0.0:*              LISTEN
exit
logout
Connection to server closed.
 
Zur Veranschaulichung folgt hier noch einmal eine grafische Darstellung dieser Beispiele:
 
Doppelter SSH-Tunnel über zwei Konsolen:
 
supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen
zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel
 
SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden:
 
supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen
 
== Verschlüsselungsdetails ==
 
=== Symmetrische Verschlüsselung ===
 
Wer als Laie an Verschlüsselung denkt, der denkt meist an die "symmetrische Verschlüsselung". Hierbei gibt es genau einen Schlüssel, mit dem ein Datensatz verschlüsselt wird.
 
Nur wer diesen Schlüssel kennt (oder durch Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren.
 
Bekannte und bewährte Algorithmen wie TripleDES, AES und Blowfish machen das Erraten des Schlüssels natürlich nicht gerade leicht, genauer gesagt, nach dem heutigen Stand der Technik nahezu unmöglich.
 
Das einzige Problem bei der Benutzung von ''symmetrischer Verschlüsselung'' ist, den Schlüssel sicher zum Kommunikationspartner zu befördern.
 
=== Asymmetrische Verschlüsselung ===
 
Um dieses Problem der ''symmetrischen Verschlüsselung'' zu umgehen, gelang es Forschern schon vor einiger Zeit, das gemeinsame Geheimnis, das für eine erfolgreiche Ver- und Entschlüsselung nötig ist, so hinter komplizierten Algorithmen zu verbergen, dass man es unter bestimmten Bedingungen öffentlich verteilen konnte.
 
Bei diesem Verfahren, ''asymmetrische Verschlüsselung'' genannt, wird nicht ein Schlüssel erzeugt, sondern ein Schlüsselpaar, das mathematisch voneinander abhängt, aber nicht ohne sehr viel Aufwand voneinander abgeleitet werden kann.
 
Jeweils zwei zueinander passende Schlüssel wirken auf geradezu magische Weise genau entgegengesetzt: Was mit dem einen Schlüssel verschlüsselt wird, kann '''nur''' durch den anderen Schlüssel wieder entschlüsselt werden.
 
Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen, um Sendungen zu verschlüsseln, die man aber '''einzig und allein''' mit dem anderen Schlüssel, den man niemals weitergibt, entschlüsseln kann.
 
Im Gegenzug kann man ein Datenpaket auch mit dem eigenen privaten Schlüssel chiffrieren. Wenn dieser Chiffretext sich dann mit dem öffentlichen Schlüssel wieder in Klartext zurückverwandeln lässt, weiß jeder, dass die Nachricht nur vom Besitzer des privaten Schlüssels kommen kann.
 
Diese Anwendungsmöglichkeit nennt man ''digitale Signatur''.
 
Da der Umgang mit asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA signifikant mehr Rechenleistung erfordert als mit symmetrischen, ist es gängige Praxis, am Beginn der Kommunikation mit Hilfe des öffentlichen Schlüssels einen neu generierten, symmetrischen ''Session-Schlüssel'' auszutauschen und für den Rest der Kommunikation auf symmetrische Verschlüsselung umzusteigen.
 
== Links ==
 
* The Secure Shell (SSH) Protocol Architecture http://www.ietf.org/rfc/rfc4251.txt
* Video vom Vortrag Ubuntu im sicheren Netz - Ubucon 2011 http://www.youtube.com/watch?v=Hxsl-jj2Bq0
* Putting the Secure in SSH - Tipps und Tricks für sicheres SSH. Blogbeitrag, 11/2014http://thepcspy.com/read/making-ssh-secure/
* Mosh - auf SSH aufsetzende Lösung für den Fernzugriff auf andere Rechnerhttps://wiki.ubuntuusers.de/Mosh/
* [http://www.harding.motd.ca/autossh/ autossh] - Monitor für SSH-Verbindungen mit Reconnect-Möglichkeit (in den Paketquellen enthalten)http://www.harding.motd.ca/autossh/
* Portweiterleitung - DSL-Router für SSH freischaltenhttps://wiki.ubuntuusers.de/Portweiterleitung/
* SSH Reverse Tunnel oder wie mache ich ein Loch in die Firewall - Reverse SSH (keine Portweiterleitung nötig)http://www.codejungle.org/site/SSH+Reverse+Tunnel+oder+wie+mache+ich+ein+Loch+in+die+Firewall.html
 
 
 
 
 
= Secure Secure Shell =
 
2015-01-04 crypto, nsa, and ssh
 
You may have heard that the NSA can decrypt SSH at least some of the time. If you have not, then read the [https://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html latest batch of Snowden documents] now. All of it. This post will still be here when you finish. My goal with this post here is to make NSA analysts sad.
 
TL;DR: Scan this post for fixed width fonts, these will be the config file snippets and commands you have to use.
 
''Warning'': You will need a recent OpenSSH version. It should work with 6.5 but I have only tested 6.7 and connections to Github. Here is a good [http://ssh-comparison.quendi.de/comparison.html compatibility matrix].
 
=== The crypto ===
 
Reading the documents, I have the feeling that the NSA can 1) decrypt weak crypto and 2) steal keys. Let’s focus on the crypto first. SSH supports different key exchange algorithms, ciphers and message authentication codes. The server and the client choose a set of algorithms supported by both, then proceed with the key exchange. Some of the supported algorithms are not so great and should be disabled completely. This hurts interoperability but everyone uses OpenSSH anyway. Fortunately, downgrade attacks are not possible because the supported algorithm lists are included in the key derivation. If a man in the middle were to change the lists, then the server and the client would calculate different keys.
 
== Key exchange ==
 
There are basically two ways to do key exchange: [https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange Diffie-Hellman] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman Elliptic Curve Diffie-Hellman]. Both provide [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy] which the NSA hates because they can’t use passive collection and key recovery later. The server and the client will end up with a shared secret number at the end without a passive eavesdropper learning anything about this number. After we have a shared secret we have to derive a cryptographic key from this using a key derivation function. In case of SSH, this is a hash function.
 
DH works with a multiplicative group of integers modulo a prime. Its security is based on the hardness of the [https://en.wikipedia.org/wiki/Discrete_logarithm_problem discrete logarithm problem].
 
Alice          Bob
<nowiki>---------------------------</nowiki>
Sa = random
Pa = g^Sa  --> Pa
                Sb = random
Pb          <-- Pb = g^Sb
s = Pb^Sa      s = Pa^Sb
k = KDF(s)      k = KDF(s)
 
ECDH works with elliptic curves over finite fields. Its security is based on the hardness of the elliptic curve discrete logarithm problem.
 
Alice          Bob
<nowiki>---------------------------</nowiki>
Sa = random
Pa = Sa * G --> Pa
                Sb = random
Pb          <-- Pb = Sb * G
s = Sa * Pb    s = Sb * Pa
k = KDF(s)      k = KDF(s)
 
OpenSSH supports 8 key exchange protocols:# [http://git.libssh.org/projects/libssh.git/tree/doc/curve25519-sha256@libssh.org.txt curve25519-sha256]: ECDH over [http://cr.yp.to/ecdh.html Curve25519] with SHA2
# [https://www.ietf.org/rfc/rfc4253.txt diffie-hellman-group1-sha1]: 1024 bit DH with SHA1
# [https://www.ietf.org/rfc/rfc4253.txt diffie-hellman-group14-sha1]: 2048 bit DH with SHA1
# [https://www.ietf.org/rfc/rfc4419.txt diffie-hellman-group-exchange-sha1]: Custom DH with SHA1
# [https://www.ietf.org/rfc/rfc4419.txt diffie-hellman-group-exchange-sha256]: Custom DH with SHA2
# ecdh-sha2-nistp256: ECDH over NIST P-256 with SHA2
# ecdh-sha2-nistp384: ECDH over NIST P-384 with SHA2
# ecdh-sha2-nistp521: ECDH over NIST P-521 with SHA2
 
 
 
We have to look at 3 things here:* ''ECDH curve choice'': This eliminates 6-8 because [http://blog.cr.yp.to/20140323-ecdsa.html NIST curves suck]. They leak secrets through timing side channels and off-curve inputs. Also, [https://projectbullrun.org/dual-ec/vulnerability.html NIST is considered harmful] and cannot be trusted.
* ''Bit size of the DH modulus'': This eliminates 2 because the NSA has supercomputers and possibly unknown attacks. 1024 bits simply don’t offer sufficient security margin.
* ''Security of the hash function'': This eliminates 2-4 because SHA1 is broken. We don’t have to wait for a second preimage attack that takes 10 minutes on a cellphone to disable it right now.
 
 
 
We are left with 1 and 5. 1 is better and it’s perfectly OK to only support that but for interoperability (with Eclipse, WinSCP), 5 can be included.
 
Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
 
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
 
Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
 
<nowiki># Github needs diffie-hellman-group-exchange-sha1 some of the time but not always.</nowiki>
<nowiki>#Host github.com</nowiki>
<nowiki># </nowiki>  KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1
 
Host *
    KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
 
If you chose to enable 5, open <tt>/etc/ssh/moduli</tt> if exists, and delete lines where the 5th column is less than 2000.
 
awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
wc -l "${HOME}/moduli" # make sure there is something left
mv "${HOME}/moduli" /etc/ssh/moduli
 
If it does not exist, create it:
 
ssh-keygen -G /etc/ssh/moduli.all -b 4096
ssh-keygen -T /etc/ssh/moduli.safe -f /etc/ssh/moduli.all
mv /etc/ssh/moduli.safe /etc/ssh/moduli
rm /etc/ssh/moduli.all
 
This will take a while so continue while it’s running.
 
== Authentication ==
 
The key exchange ensures that the server and the client shares a secret no one else knows. We also have to make sure that they share this secret with each other and not an NSA analyst.
 
=== Server authentication ===
 
The server proves its identity to the client by signing the key resulting from the key exchange. There are 4 public key algorithms for authentication:# DSA with SHA1
# ECDSA with SHA256, SHA384 or SHA512 depending on key size
# [http://ed25519.cr.yp.to/ Ed25519] with SHA512
# RSA with SHA1
 
 
 
DSA keys must be exactly 1024 bits so let’s disable that. Number 2 here involves NIST suckage and should be disabled as well. Another important disadvantage of DSA and ECDSA is that it uses randomness for each signature. If the random numbers are not the best quality, then it is [https://security.stackexchange.com/a/46781 possible to recover] the [https://events.ccc.de/congress/2010/Fahrplan/attachments/1780%5F27c3%5Fconsole%5Fhacking%5F2010.pdf secret key]. Fortunately, RSA using SHA1 is not a problem here because the value being signed is actually a SHA2 hash. The hash function SHA1(SHA2(x)) is just as secure as SHA2 (it has less bits of course but no better attacks).
 
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
 
The first time you connect to your server, you will be asked to accept the new fingerprint.
 
This will also disable the horribly broken v1 protocol that you should not have enabled in the first place. We should remove the unused keys and only generate a large RSA key and an Ed25519 key. Your init scripts may recreate the unused keys. If you don’t want that, remove any <tt>ssh-keygen</tt> commands from the init script.
 
cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key < /dev/null
 
=== Client authentication ===
 
The client must prove its identity to the server as well. There are various methods to do that.
 
The simplest is password authentication. This should be disabled immediately ''after'' setting up a more secure method because it allows compromised servers to steal passwords. Password authentication is also more vulnerable to online bruteforce attacks.
 
Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
 
PasswordAuthentication no
ChallengeResponseAuthentication no
 
Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
 
Host *
    PasswordAuthentication no
    ChallengeResponseAuthentication no
 
The most common and secure method is public key authentication, basically the same process as the server authentication.
 
Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
 
PubkeyAuthentication yes
 
Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
 
Host *
    PubkeyAuthentication yes
    HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa
 
Generate client keys using the following commands:
 
ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100
 
You can deploy your new client public keys using <tt>ssh-copy-id</tt>.
 
It is also possible to use OTP authentication to reduce the consequences of lost passwords. [https://code.google.com/p/google-authenticator/wiki/PamModuleInstructions Google Authenticator] is a nice implementation of [https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm TOTP], or Timebased One Time Password. You can also use a [https://www.cl.cam.ac.uk/%7Emgk25/otpw.html printed list of one time passwords] or any other [https://en.wikipedia.org/wiki/Pluggable_authentication_module PAM] module, really, if you enable <tt>ChallengeResponseAuthentication</tt>.
 
=== User Authentication ===
 
Even with Public Key authentication, you should only allow incoming connections from expected users. The <tt>AllowUsers</tt> setting in <tt>sshd_config</tt> lets you specify users who are allowed to connect, but this can get complicated with a large number of ssh users. Additionally, when deleting a user from the system, the username is [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=779880 not removed] from <tt>sshd_config</tt>, which adds to maintenance requirements. The solution is to use the <tt>AllowGroups</tt> setting instead, and add users to an <tt>ssh-user</tt> group.
 
Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
 
AllowGroups ssh-user
 
Create the ssh-user group with <tt>sudo groupadd ssh-user</tt>, then add each ssh user to the group with <tt>sudo usermod -a -G ssh-user <username></tt>.
 
== Symmetric ciphers ==
 
Symmetric ciphers are used to encrypt the data after the initial key exchange and authentication is complete.
 
Here we have quite a few algorithms:# 3des-cbc
# aes128-cbc
# aes192-cbc
# aes256-cbc
# aes128-ctr
# aes192-ctr
# aes256-ctr
# aes128-gcm@openssh.com
# aes256-gcm@openssh.com
# arcfour
# arcfour128
# arcfour256
# blowfish-cbc
# cast128-cbc
# chacha20-poly1305@openssh.com
 
 
 
We have to consider the following:* ''Security of the cipher algorithm'': This eliminates 1 and 10-12 - both DES and RC4 are broken. Again, no need to wait for them to become even weaker, disable them now.
* ''Key size'': At least 128 bits, the more the better.
* ''Block size'': Does not apply to stream ciphers. At least 128 bits. This eliminates 13 and 14 because those have a 64 bit block size.
* ''Cipher mode'': The recommended approach here is to prefer [https://en.wikipedia.org/wiki/Authenticated_encryption AE] modes and optionally allow CTR for compatibility. CTR with Encrypt-then-MAC is provably secure.
 
 
 
Chacha20-poly1305 is preferred over AES-GCM because the SSH protocol [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html does not encrypt message sizes] when GCM (or EtM) is in use. This allows some traffic analysis even without decrypting the data. We will deal with that soon.
 
Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
 
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 
Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
 
Host *
    Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 
== Message authentication codes ==
 
Encryption provides ''confidentiality'', message authentication code provides ''integrity''. We need both. If an AE cipher mode is selected, then extra MACs are not used, the integrity is already given. If CTR is selected, then we need a MAC to calculate and attach a tag to every message.
 
There are multiple ways to combine ciphers and MACs - not all of these are useful. The 3 most common:* ''Encrypt-then-MAC'': encrypt the message, then attach the MAC of the ciphertext.
* ''MAC-then-encrypt'': attach the MAC of the plaintext, then encrypt everything.
* ''Encrypt-and-MAC'': encrypt the message, then attach the MAC of the plaintext.
 
 
 
Only Encrypt-then-MAC should be used, period. Using MAC-then-encrypt have lead to many attacks on TLS while Encrypt-and-MAC have lead to not quite that many attacks on SSH. The reason for this is that the more you fiddle with an attacker provided message, the more chance the attacker has to gain information through side channels. In case of Encrypt-then-MAC, the MAC is verified and if incorrect, discarded. Boom, one step, no timing channels. In case of MAC-then-encrypt, first the attacker provided message has to be decrypted and only then can you verify it. Decryption failure (due to invalid CBC padding for example) may take less time than verification failure. Encrypt-and-MAC also has to be decrypted first, leading to the same kind of potential side channels. It’s even worse because no one said that a MAC’s output can’t leak what its input was. SSH by default, uses this method.
 
Here are the available MAC choices:# hmac-md5
# hmac-md5-96
# hmac-ripemd160
# hmac-sha1
# hmac-sha1-96
# hmac-sha2-256
# hmac-sha2-512
# umac-64
# umac-128
# hmac-md5-etm@openssh.com
# hmac-md5-96-etm@openssh.com
# hmac-ripemd160-etm@openssh.com
# hmac-sha1-etm@openssh.com
# hmac-sha1-96-etm@openssh.com
# hmac-sha2-256-etm@openssh.com
# hmac-sha2-512-etm@openssh.com
# umac-64-etm@openssh.com
# umac-128-etm@openssh.com
 
 
 
The selection considerations:* ''Security of the hash algorithm'': No MD5 and SHA1. Yes, I know that HMAC-SHA1 does not need collision resistance but why wait? Disable weak crypto today.
* ''Encrypt-then-MAC'': I am not aware of a security proof for CTR-and-HMAC but I also don’t think CTR decryption can fail. Since there are no downgrade attacks, you can add them to the end of the list. You can also do this on a host by host basis so you know which ones are less safe.
* ''Tag size'': At least 128 bits. This eliminates umac-64-etm.
* ''Key size'': At least 128 bits. This doesn’t eliminate anything at this point.
 
 
 
Recommended <tt>/etc/ssh/sshd_config</tt> snippet:
 
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
 
Recommended <tt>/etc/ssh/ssh_config</tt> snippet:
 
Host *
    MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com
 
=== Preventing key theft ===
 
Even with forward secrecy the secret keys must be kept secret. The NSA has a database of stolen keys - you do not want your key there.
 
== System hardening ==
 
This post is not intended to be a comprehensive system security guide. Very briefly:* ''Don’t install what you don’t need'': Every single line of code has a chance of containing a bug. Some of these bugs are security holes. Fewer lines, fewer holes.
* ''Use free software'': As in speech. You want to use code that’s actually reviewed or that you can review yourself. There is no way to achieve that without source code. Someone may have reviewed proprietary crap but who knows.
* ''Keep your software up to date'': New versions often fix critical security holes.
* ''Exploit mitigation'': Sad but true - there will always be security holes in your software. There are things you can do to prevent their exploitation, such as GCC’s -fstack-protector. One of the best security projects out there is [https://grsecurity.net/ Grsecurity]. Use it or use OpenBSD.
 
 
 
== Traffic analysis resistance ==
 
Set up [https://www.torproject.org/docs/hidden-services.html.en Tor hidden services] for your SSH servers. This has multiple advantages. It provides an additional layer of encryption and server authentication. People looking at your traffic will not know your IP, so they will be unable to scan and target other services running on the same server and client. Attackers can still attack these services but don’t know if it has anything to do with the observed traffic until they actually break in.
 
Now this is only true if you don’t disclose your SSH server’s fingerprint in any other way. You should only accept connections from the hidden service or from LAN, if required.
 
If you don’t need LAN access, you can add the following line to <tt>/etc/ssh/sshd_config</tt>:
 
ListenAddress 127.0.0.1:22
 
Add this to <tt>/etc/tor/torrc</tt>:
 
HiddenServiceDir /var/lib/tor/hidden_service/ssh
HiddenServicePort 22 127.0.0.1:22
 
You will find the hostname you have to use in <tt>/var/lib/tor/hidden_service/ssh/hostname</tt>. You also have to configure the client to use Tor. For this, socat will be needed. Add the following line to <tt>/etc/ssh/ssh_config</tt>:
 
Host *.onion
    ProxyCommand socat - SOCKS4A:localhost:%h:%p,socksport=9050
 
Host *
    ...
 
If you want to allow connections from LAN, don’t use the <tt>ListenAddress</tt> line, configure your firewall instead.
 
== Key storage ==
 
You should encrypt your client key files using a strong password. Additionally, you can use <tt>ssh-keygen -o -a $number</tt> to slow down cracking attempts by iterating the hash function many times. You may want to store them on a pendrive and only plug it in when you want to use SSH. Are you more likely to lose your pendrive or have your system compromised? I don’t know.
 
Unfortunately, you can’t encrypt your server key and it must be always available, or else sshd won’t start. The only thing protecting it is OS access controls.
 
=== The end ===
 
It’s probably a good idea to test the changes. <tt>ssh -v</tt> will print the selected algorithms and also makes problems easier to spot. Be extremely careful when configuring SSH on a remote host. Always keep an active session, never restart sshd. Instead you can send the <tt>SIGHUP</tt> signal to reload the configuration without killing your session. You can be even more careful by starting a new sshd instance on a different port and testing that.
 
Can you make these changes? If the answer is yes, then…
 
If the answer is no, it’s probably due to compatibility problems. You can try to convince the other side to upgrade their security and turn it into a yes. I have created a [https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-Shell wiki page] where anyone can add config files for preserving compatibility with various SSH implementations and SSH based services.
 
If you work for a big company and change management doesn’t let you do it, I’m sorry. I’ve seen the v1 protocol enabled in such places. There is no chance of improvement. Give up to preseve your sanity.
 
Special thanks to the people of Twitter for the improvements.
 
= OpenSSH server =
 
== Configuration ==
 
Different versions of OpenSSH support different options which are not always compatible. This guide shows settings for the most commonly deployed OpenSSH versions at Mozilla - however, using the latest version of OpenSSH is recommended.
 
=== Modern (OpenSSH 6.7+) ===
 
File: <tt>/etc/ssh/sshd_config</tt>
 
<nowiki># Supported HostKey algorithms by order of preference.</nowiki>
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
 
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
 
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
 
<nowiki># Password based logins are disabled - only public key based logins are allowed.</nowiki>
AuthenticationMethods publickey
 
<nowiki># LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.</nowiki>
LogLevel VERBOSE
 
<nowiki># Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.</nowiki>
Subsystem sftp  /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
 
<nowiki># Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:</nowiki>
<nowiki>#</nowiki>
<nowiki># On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.</nowiki>
<nowiki># Additionally, only tools such as systemd and auditd record the process session id.</nowiki>
<nowiki># On other OSes, the user session id is not necessarily recorded at all kernel-side.</nowiki>
<nowiki># Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.</nowiki>
PermitRootLogin No
 
<nowiki># Use kernel sandbox mechanisms where possible in unprivileged processes</nowiki>
<nowiki># Systrace on OpenBSD, Seccomp on Linux, seatbelt on MacOSX/Darwin, rlimit elsewhere.</nowiki>
UsePrivilegeSeparation sandbox
 
File: <tt>/etc/ssh/moduli</tt>
 
All Diffie-Hellman moduli in use should be at least 3072-bit-long (they are used for <tt>diffie-hellman-group-exchange-sha256</tt>) as per our [https://wiki.mozilla.org/Security/Guidelines/Key_Management Security/Guidelines/Key_Management] recommendations. See also <tt>man moduli</tt>.
 
To deactivate short moduli in two commands: <tt>awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli</tt>
 
 
=== Intermediate (OpenSSH 5.3) ===
 
This is mainly for use by RHEL6, CentOS6, etc. which run older versions of OpenSSH.
 
File: <tt>/etc/ssh/sshd_config</tt>
 
<nowiki># Supported HostKey algorithms by order of preference.</nowiki>
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
 
KexAlgorithms diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512,hmac-sha2-256
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
 
<nowiki># Password based logins are disabled - only public key based logins are allowed.</nowiki>
RequiredAuthentications2 publickey
 
<nowiki># RequiredAuthentications2 not work on official OpenSSH 5.3 portable.</nowiki>
<nowiki># In this is your case, use this instead:</nowiki>
<nowiki>#PubkeyAuthentication yes</nowiki>
<nowiki>#PasswordAuthentication no</nowiki>
 
<nowiki># LogLevel VERBOSE logs user's key fingerprint on login. Needed to have a clear audit track of which key was using to log in.</nowiki>
LogLevel VERBOSE
 
<nowiki># Log sftp level file access (read/write/etc.) that would not be easily logged otherwise.</nowiki>
Subsystem sftp  /usr/lib/ssh/sftp-server -f AUTHPRIV -l INFO
 
<nowiki># Root login is not allowed for auditing reasons. This is because it's difficult to track which process belongs to which root user:</nowiki>
<nowiki>#</nowiki>
<nowiki># On Linux, user sessions are tracking using a kernel-side session id, however, this session id is not recorded by OpenSSH.</nowiki>
<nowiki># Additionally, only tools such as systemd and auditd record the process session id.</nowiki>
<nowiki># On other OSes, the user session id is not necessarily recorded at all kernel-side.</nowiki>
<nowiki># Using regular users in combination with /bin/su or /usr/bin/sudo ensure a clear audit track.</nowiki>
PermitRootLogin No
 
File: <tt>/etc/ssh/moduli</tt>
 
All Diffie-Hellman moduli in use should be at least 2048-bit-long. From the structure of <tt>moduli</tt> files, this means the fifth field of all lines in this file should be greater than or equal to 2047.
 
To deactivate weak moduli in two commands: <tt>awk '$5 >= 2047' /etc/ssh/moduli > /etc/ssh/moduli.tmp && mv /etc/ssh/moduli.tmp /etc/ssh/moduli</tt>
 
=== Multi-Factor Authentication (OpenSSH 6.3+) ===
 
Recent versions of OpenSSH support MFA (Multi-Factor Authentication). Using MFA is recommended where possible.
 
It requires additional setup, such as using the [http://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com/ DuoSecurity].
 
 
{| style="border-spacing:0;width:17.501cm;"
|- style="border:none;padding:0.049cm;"
|| <span style="color:#ff0000;">'''ATTENTION</span> '''
|- style="border:none;padding:0.049cm;"
|| In order to allow using one time passwords (OTPs) and any other text input, Keyboard-interactive is enabled in OpenSSH. This ''MAY'' allow for password authentication to work. It is therefore very important to check your PAM configuration so that PAM disallow password authentication for OpenSSH.


=== Sicherheit ===
# [[SSH/Kryptografie]]


=== Dokumentation ===
==== RFC ====
{| class="wikitable sortable options"
|-
! RFC !! Title
|-
| 4251 || [https://tools.ietf.org/html/rfc4251  The Secure Shell (SSH) Protocol Architecture ]
|-
| 4252 || [https://tools.ietf.org/html/rfc4252  The Secure Shell (SSH) Authentication Protocol ]
|-
| 4253 || [https://tools.ietf.org/html/rfc4253  The Secure Shell (SSH) Transport Layer Protocol ]
|-
| 6668 || [https://tools.ietf.org/html/rfc6668  SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol ]
|-
| 8268 || [https://tools.ietf.org/html/rfc8268  More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH) ]
|-
|-
|}
| 8308 || [https://tools.ietf.org/html/rfc8308  Extension Negotiation in the Secure Shell (SSH) Protocol ]
==== OpenSSH 6.3+ (default) ====
 
File: <tt>/etc/ssh/sshd_config</tt>
 
<nowiki># IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd</nowiki>
<nowiki># "PasswordAuthentication no" is not sufficient!</nowiki>
PubkeyAuthentication yes
PasswordAuthentication no
AuthenticationMethods publickey,keyboard-interactive:pam
KbdInteractiveAuthentication yes
UsePAM yes
<nowiki># Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.</nowiki>
UseLogin no
 
==== OpenSSH 5.3+ w/ RedHat/CentOS patch (old) ====
 
File: <tt>/etc/ssh/sshd_config</tt>
 
<nowiki># Allow keyboard-interactive.</nowiki>
<nowiki># IMPORTANT: you will have to ensure OpenSSH cannot authenticate with passwords with PAM in /etc/pam.d/sshd</nowiki>
<nowiki># "PasswordAuthentication no" is not sufficient!</nowiki>
RequiredAuthentications2 publickey,keyboard-interactive:skey
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
<nowiki># Ensure /bin/login is not used so that it cannot bypass PAM settings for sshd.</nowiki>
UseLogin no
 
PAM configuration for use with the [https://www.nongnu.org/oath-toolkit/ OATH Toolkit] or [https://www.duosecurity.com/ DuoSecurity] as second authentication factor.
 
File: <tt>/etc/pam.d/sshd</tt>
 
<nowiki>#%PAM-1.0</nowiki>
auth      required    pam_sepermit.so
 
<nowiki># WARNING: make sure any password authentication module is disabled.</nowiki>
<nowiki># Example: pam_unix.so, or "password-auth", "system-auth", etc.</nowiki>
<nowiki>#auth </nowiki>      include      password-auth
 
<nowiki># Options to enable when using OATH toolkit</nowiki>
<nowiki>#auth </nowiki>      requisite    pam_oath.so usersfile=/etc/users.oath digits=6 window=20
 
<nowiki># Options to enable when using DuoSecurity</nowiki>
<nowiki>#auth </nowiki>  sufficient      /lib64/security/pam_duo.so
 
account    required    pam_nologin.so
 
== Ciphers and algorithms choice ==
 
* When CHACHA20 (OpenSSH 6.5+) is not available, AES-GCM (OpenSSH 6.1+) and any other algorithm using EtM (Encrypt then MAC) [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html disclose the packet length] - giving some information to the attacker. Only recent OpenSSH servers and client support CHACHA20.
 
* NIST curves (<tt>ecdh-sha2-nistp512,ecdh-sha2-nistp384,ecdh-sha2-nistp256</tt>) are listed for compatibility, but the use of <tt>curve25519</tt> is [https://safecurves.cr.yp.to/ generally preferred].
 
* SSH protocol 2 supports [https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange DH] and [https://en.wikipedia.org/wiki/Elliptic_curve_Diffie–Hellman ECDH] key-exchange as well as [https://en.wikipedia.org/wiki/Forward_secrecy forward secrecy]. Regarding group sizes, please refer to [https://wiki.mozilla.org/Security/Guidelines/Key_Management Security/Guidelines/Key_Management].
 
 
 
The various algorithms supported by a particular OpenSSH version can be listed with the following commands:
 
$ ssh -Q cipher
$ ssh -Q cipher-auth
$ ssh -Q mac
$ ssh -Q kex
$ ssh -Q key
 
= OpenSSH client =
 
== Configuration ==
 
If you have a file containing known_hosts using RSA or ECDSA host key algorithm and the server now supports ed25519 for example, you will get a warning that the host key has changed and will be unable to connect. This means you will have to verify the new host key.
 
The following configurations expect a recent OpenSSH client, as updating OpenSSH on the client side is generally not an issue.
 
=== Modern ===
 
This configuration is less compatible and you may not be able to connect to some servers which use insecure, deprecated algorithms. Nevertheless, modern servers will work just fine.
 
File: <tt>~/.ssh/config</tt>
 
<nowiki># Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.</nowiki>
HashKnownHosts yes
<nowiki># Host keys the client accepts - order here is honored by OpenSSH</nowiki>
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
 
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
 
=== Intermediate (connects to older servers) ===
 
This configuration can connect to older OpenSSH servers which run old or intermediate configurations.
 
File: <tt>~/.ssh/config</tt>
 
<nowiki># Ensure KnownHosts are unreadable if leaked - it is otherwise easier to know which hosts your keys have access to.</nowiki>
HashKnownHosts yes
<nowiki># Host keys the client accepts - order here is honored by OpenSSH</nowiki>
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256
 
== Key generation ==
 
Large key sizes are used as SSH keys are not renewed very often (see also [https://wiki.mozilla.org/Security/Key_Management Security/Key_Management]).
 
<div style="margin-left:1cm;margin-right:1cm;">'''''Note:''' ''</div>
 
<div style="margin-left:1cm;margin-right:1cm;">''DSA and RSA 1024 bit (or lower) keys are considered weak and should be replaced as soon as possible. ''</div>
 
Don't hesitate to create multiple different keys for different usages. In particular, never mix your personal and Mozilla keys.
 
<nowiki># RSA keys are favored over ECDSA keys when backward compatibility ''is required'',</nowiki>
<nowiki># thus, newly generated keys are always either ED25519 or RSA (NOT ECDSA or DSA).</nowiki>
$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"
 
<nowiki># ED25519 keys are favored over RSA keys when backward compatibility ''is not required''.</nowiki>
<nowiki># This is only compatible with OpenSSH 6.5+ and fixed-size (256 bytes).</nowiki>
$ ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_mozilla_$(date +%Y-%m-%d) -C "Mozilla key for xyz"
 
You may then want to add the new key to your SSH agent or your configuration file (or both).
 
<nowiki># Add key to ssh-agent</nowiki>
$ ssh-add ~/.ssh/id_..._mozilla... # <= replace by your key's path
<nowiki># Add configuration to ~/.ssh/config</nowiki>
host *.mozilla.com
IdentityFile ~/.ssh/id_...mozilla... # <= replace by your key's path
 
=== Protection of user keys ===
 
* Protected by strong passphrase.
* Never copied to another system than your own workstation/personal physical disks/tokens.
* Use SSH forwarding or SSH tunneling if you need to jump between hosts. '''DO NOT''' maintain unnecessary agent forwarding when unused.
 
 
 
=== Protection of machine keys ===
 
When SSH keys are necessary for automation between systems, it is reasonable to use passphrase-less keys. * The recommended settings are identical to the user keys.
* The keys must be accessible only by the admin user (root) and/or the system user requiring access.
* Usage of machine keys should be registered in an inventory (a wiki page, ldap, an inventory database), to allow for rapid auditing of key usage across an infrastructure.
* The machine keys should be unique per usage. Each new usage (different service, different script called, etc.) should use a new, different key.
* Only used when strictly necessary.
* Restrict privileges of the account (i.e. no root or "sudoer" machine account).
* Using a ForceCommand returning only the needed results, or only allowing the machine to perform SSH-related tasks such as tunneling is prefered.
* Disable sftp if not needed as it exposes more surface and different logging mechanisms than SSH (and thus scp) itself.
 
 
 
<div style="margin-left:1cm;margin-right:1cm;">'''''Note:''' ''</div>
 
<div style="margin-left:1cm;margin-right:1cm;">''You may want to use the group "users" instead of "sftpusers" in the example below as this may already exist and include all regular users by default. ''</div>
 
    <nowiki># groupadd sftpusers</nowiki>
    <nowiki># usermod -a -g sftpusers <userthat_needs_ftp></nowiki>
    <nowiki># chgrp sftpusers /usr/lib/ssh/sftp-server</nowiki>
    <nowiki># chmod 0750 /usr/lib/ssh/sftp-server</nowiki>
 
==== Multi-factor bypass setup for machine keys ====
 
Machine keys do not play well with multi-factor authentication as there is no human interaction. * All logins from machine accounts should be protected by an additional authentication layer (VPN, another machine, etc.).
* All logins from machine accounts are only allowed within the private IP-space, and if possible, only the relevant machine source IPs should be accessible.
 
 
 
File: <tt>/etc/ssh/sshd_config</tt> (OpenSSH 6.3+)
 
Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
    PubkeyAuthentication yes
    KbdInteractiveAuthentication no
    AuthenticationMethods publickey
 
File: <tt>/etc/ssh/sshd_config</tt> (OpenSSH 5.3+ w/ RedHat/CentOS patch)
 
Match User machine_user Address 10.0.0.0/8,192.168.0.0/16,172.16.0.0/12
    RequiredAuthentications2 publickey
 
=== Auditing your existing SSH keys ===
 
Existing keys are generally stored in <tt>~/.ssh/</tt> (Linux/OSX) or <tt>%APPDATA%</tt> (Windows). Look for <tt>id_{rsa,ed25519,ecdsa,dsa}, identity, IdentityFile, *.pem</tt>, and other <tt>identity</tt> files.
 
==== Display SSH keys information ====
 
<nowiki># You may run this for any key file that you have.</nowiki>
$ ssh-keygen -lf id_rsa
2048 bc:4f:46:2b:3d:f1:e2:0f:ac:40:99:49:ed:c9:81:a2 Mozilla key for xyz (RSA)
^^  ^^^^^^^^^                                      ^^^^                ^^^
|__ Size    |__ Fingerprint                            |__ Comment        |__ Type
 
== SSH agent forwarding ==
 
 
{| style="border-spacing:0;width:17.501cm;"
|- style="border:none;padding:0.049cm;"
|| <span style="color:#ff0000;">'''ATTENTION</span> '''
|- style="border:none;padding:0.049cm;"
|| SSH Agent forwarding exposes your authentication to the server you're connecting to. By default, an attacker with control of the server (i.e. root access) can communicate with your agent and use your key to authenticate to other servers without any notification (i.e. impersonate you).For this reason, one must be careful when using SSH agent forwarding. Defaulting to always forwarding the agent is strongly discouraged.Note also that while the attacker can use your key as long as the agent is running and forwarded, he cannot steal/download the key for offline/later use.
|-
|-
| 8332 || [https://tools.ietf.org/html/rfc8332  Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol ]
|}
|}
SSH forwarding allows you to jump between hosts while keeping your private key on your local computer. This is accomplished by telling SSH to forward the authentication requests back to the ssh-agent of your local computer. SSH forwarding works between as many hosts as needed, each host forwarding new authentication request to the previous host, until the ssh-agent that holds the private key is reached.
[[Image:Bild1.png|top|alt="Ssh forwarding.png"]]
On each host, two environment variables are declared for the user enabling ssh-agent: * '''$SSH_AUTH_SOCK''' declares the location of the unix socket that can be used to forward an authentication request back to the previous host.(ex: /tmp/ssh-NjPxtt8779/agent.8779). Only present if using SSH agent forwarding.
* '''$SSH_CONNECTION''' shows the source IP and port of the previous host, as well as the local IP and port. (ex: 10.22.248.74 44727 10.8.75.110 22).
To use ssh-agent, add the flag <tt>-A</tt> to your ssh commands:
$ ssh -A user@ssh.mozilla.com
You can set the following configuration parameter in your local ssh configuration at ~/.ssh/config.
Host ssh.mozilla.com
    ForwardAgent yes
=== Hardening the Agent forwarder ===
It is possible to require confirmation every time the agent is used (i.e. when you connect to a server through the SSH agent) by using the <tt>-c</tt> flag:
<nowiki># First, remove the key from the agent if it's already loaded:</nowiki>
$ ssh-add -d ~/.ssh/id_ed25519
<nowiki># And re-add it with the -c flag:</nowiki>
$ ssh-add -c ~/.ssh/id_ed25519
It is also possible to lock the key in the agent after a configurable amount of time, this can be done either for all keys when starting the agent, or per key when adding the keys to the agent with the <tt>-t</tt> flag:
<nowiki># Keep all keys decrypted/useable in memory for 30 minutes (1800 seconds)</nowiki>
$ ssh-agent -t 1800
<nowiki># First, remove the key from the agent if it's already loaded:</nowiki>
$ ssh-add -d ~/.ssh/id_ed25519
<nowiki># Re-add it, with the -t flag to keep this specific key decrypted/useable in memory for 30 minutes (1800 seconds)</nowiki>
$ ssh-add -t 1800 ~/.ssh/id_ed25519
For MacOSX in particular it's possible to save the passphrase in the Keychain. If you do so it is strongly recommended to also change the keychain setting to lock itself when the computer is locked, and/or to timeout and lock the keychain. These settings are not controlled by OpenSSH.
<nowiki># MacOSX only - save the passphrase in the Keychain</nowiki>
$ ssh-add -K ~/.ssh/id_ed25519
<div style="margin-left:1cm;margin-right:1cm;">'''''Note:''' ''</div>
<div style="margin-left:1cm;margin-right:1cm;">''There are also some third-party patches for various OpenSSH clients that will notify you visually when the agent is being used. ''</div>
<div style="margin-left:1cm;margin-right:1cm;">''These are not officially supported and may require you to recompile OpenSSH. ''</div>* [https://github.com/gdestuynder/openssh-portable/commits/libnotify OpenSSH Linux] ''
* [https://github.com/gdestuynder/putty-pagent-notification/commits/master PuTTY/Pageant] ''
* [https://github.com/gdestuynder/gnupg-agent-notification/commit/57697146188d52f5447a50303070371a8cf5c0bb GnuPG Agent Linux] ''
* [https://github.com/devinteske/apple/tree/master/OpenSSH-186/openssh OpenSSH MacOS X] (see also [http://devinteske.com/ http://devinteske.com/])''
=== Recommended, safer alternatives to SSH agent forwarding ===
==== OpenSSH >=7.3 ====
OpenSSH 7.3 onwards allow users to jump through several hosts in a rather automated fashion. It has full support for scp and sftp commands as well as regular ssh.
For example to reach a host behind a bastion/jumphost:
<nowiki># Single jump</nowiki>
$ ssh -J ssh.mozilla.com myhost.private.scl3.mozilla.com
<nowiki># Jump through 2 hops</nowiki>
$ ssh -J ssh.mozilla.com,ec2-instance.aws.net 10.0.0.3
<nowiki># Copy data from a host</nowiki>
$ scp -oProxyJump=ssh.mozilla.com myhost.private.scl3.mozilla.com:/home/kang/testfile ./
You can also add these lines to your <tt>~/.ssh/config</tt>
Host *.mozilla.com !ssh.mozilla.com
ProxyJump ssh.mozilla.com
==== Older versions of OpenSSH ====
It is possible to directly forward ports for single jumps instead of forwarding the agent. This has the advantage of never exposing your agent to the servers you're connecting to.
For example, you can add these lines to your <tt>~/.ssh/config</tt>
Host *.mozilla.com !ssh.mozilla.com
ProxyCommand ssh ssh.mozilla.com -W %h:%p
This will automatically forward the SSH connection over ssh.mozilla.com when you connect to a mozilla.com SSH server.
= Appendixes =
== Key material handling ==
Key material identifies the cryptographic secrets that compose a key. All key material must be treated as <span style="color:#ffa500;">RESTRICTED</span> data, meaning that: * Only individual with specific training and need-to-know should have access to key material.
* Key material must be encrypted on transmission.
* Key material can be stored in clear text, but only with proper access control (limited access).
This includes: * OpenSSH server keys (<tt>/etc/ssh/ssh_host_*key</tt>)
* Client keys (<tt>~/.ssh/id_{rsa,dsa,ecdsa,ed25519}</tt> and <tt>~/.ssh/identity</tt>).
== Client key size and login latency ==
In order to figure out the impact on performance of using larger keys - such as RSA 4096 bytes keys - on the client side, we have run a few tests:
On an idle, i7 4500 intel CPU using OpenSSH_6.7p1, OpenSSL 1.0.1l and ed25519 server keys the following command is ran 10 times:
<tt>time ssh localhost -i .ssh/id_thekey exit</tt>


Results:
=== Links ===
 
==== Projekt ====
 
==== Weblinks ====
{| style="border-spacing:0;width:6.846cm;"
|- style="border:none;padding:0.049cm;"
|| '''Client key '''
|| '''Minimum '''
|| '''Maximum '''
|| '''Average '''
|- style="border:none;padding:0.049cm;"
|| RSA 4096
|| 120ms
|| 145ms
|| 127ms
|- style="border:none;padding:0.049cm;"
|| RSA 2048
|| 120ms
|| 129ms
|| 127ms
|- style="border:none;padding:0.049cm;"
|| ed25519
|| 117ms
|| 138ms
|| 120ms
|-
|}
Keep in mind that these numbers may differ on a slower machine, and that this contains the complete login sequence and therefore is subject to variations. However, it seems safe to say that the latency differences are not significant and do not impact performance sufficiently to cause any concern regardless of the type of key used.


== Reference documents ==
<noinclude>


* [https://wiki.mozilla.org/Security/Key_Management Key Management]
</noinclude>
* [https://wiki.mozilla.org/Security/Server_Side_TLS Server Side TLS]
* [https://www.ietf.org/rfc/rfc4418.txt RFC4418 (umac)]
* [http://www.openssh.com/txt/draft-miller-secsh-umac-01.txt umac draft]
* [https://safecurves.cr.yp.to/ Safe curves]
* [http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html DJM blog]
* [https://stribika.github.io/2015/01/04/secure-secure-shell.html Stribika blog]
* [http://2013.diac.cr.yp.to/slides/gueron.pdf AES-GCM performance study]
* [https://security.googleblog.com/2014/04/speeding-up-and-strengthening-https.html CHACHA20 vs AES-GCM performance study]
* [http://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/src/usr.bin/ssh/PROTOCOL.certkeys?rev=1.9&content-type=text/plain PROTOCOL.certkeys]
* [https://wiki.gnupg.org/rfc4880bis rfc44880bis from GnuPG]
* [https://weakdh.org/ Weak Diffie-Hellman and the Logjam Attack]
* [https://jbeekman.nl/blog/2015/05/ssh-logjam/ On OpenSSH and Logjam, by Jethro Beekman]


[[Category:Entwurf]]
[[Kategorie:SSH]]
[[Kategorie:Telnet]]

Aktuelle Version vom 11. September 2024, 09:42 Uhr

Secure Shell (SSH) - kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke

Beschreibung

Verwendung
  • Fernzugriff auf Computersysteme
  • Sichere Übertragung von Dateien über nicht vertrauenswürdige Netzwerke
  • Entfernte Kommandozeile
    • auf einer lokalen Konsole werden die Ausgaben der entfernten Konsole ausgegeben
    • lokale Tastatureingaben werden an den entfernten Rechner gesendet
Verfügbarkeit
Ziele

Authentifizierung

  • Authentifizierung der Gegenstelle
  • Kein Ansprechen falscher Ziele

Vertraulichkeit

  • Kryptografie der Datenübertragung

Integrität

  • Keine Manipulation der übertragenen Daten
Port Zuordnung
Client–Server-Architektur

Eine SSH-Client-Anwendung verbindet sich mit einem SSH-Server

Protokollspezifikation
  • SSH-1
  • SSH-2
Fernwartung
  • Genutzt werden kann dies z. B.  zur Fernwartung eines in einem entfernten Rechenzentrum stehenden Servers.
  • Die neuere Protokoll-Version SSH-2 bietet weitere Funktionen wie Datenübertragung per SFTP.

Ersatz für Telnet

  • Bestandteil aller Linux- und Unix-Distributionen
  • Dabei dient SSH als Ersatz für andere, unsichere Methoden wie Telnet.
  • Bei diesen werden alle Informationen, auch sensible wie etwa Passwörter, im Klartext übertragen.
  • Dies macht sie anfällig für Man-in-the-Middle-Angriffe sowie einen Vertraulichkeitsverlust durch Packet Analyzer, die die Datenpakete mitschneiden. Die Kryptografiestechnik, die durch SSH genutzt wird, hat deshalb den Zweck, die Vertraulichkeit, Integrität und Authentizität von Daten, die über ein unsicheres Netzwerk (wie z. B.  das Internet) gesendet werden, sicherzustellen.

Siehe auch

Sicherheit

  1. SSH/Kryptografie

Dokumentation

RFC

RFC Title
4251 The Secure Shell (SSH) Protocol Architecture
4252 The Secure Shell (SSH) Authentication Protocol
4253 The Secure Shell (SSH) Transport Layer Protocol
6668 SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
8268 More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
8308 Extension Negotiation in the Secure Shell (SSH) Protocol
8332 Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol

Links

Projekt

Weblinks

Abgerufen von „https://wiki.foxtom.de/index.php?title=Secure_Shell&oldid=107828“