[[Vorlage(Getestet, focal, bionic)]] [[Vorlage(Fortgeschritten)]] {{{#!vorlage Wissen [:Pakete_installieren: Installation von Programmen] [:Terminal: Ein Terminal öffnen] [:Shell: Umgang mit der Kommandozeile] [:Sicherheits_1x1: Sicherheits-Einmaleins] [:Autostart: Automatischer Start von Programmen] (optional) }}} [[Inhaltsverzeichnis(2)]] [[Bild(Wiki/Icons/security.png, 48, align=left)]] Es gab einmal eine Zeit, als Computer im Netz über das [wikipedia: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] {en} und bot die Version 2 der SSH-Suite nur noch kommerziell an. Daraufhin wurde von Entwicklern des Betriebssystems [wikipedia:OpenBSD:] der öffentliche Quellcode der Version 1 [wikipedia: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 [#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 [:Portweiterleitung:] einrichten, sonst kommt keine Verbindung zustande. [[Anker(SSH-Client)]] = Der SSH-Client = Das funktioniert normalerweise in einem Terminal-Fenster[2] so: {{{#!vorlage Befehl ssh pi@192.168.178.38 }}} Mit diesem Befehl verbindet man sich als Nutzer `pi` auf dem Rechner mit der IP-Adresse `192.168.178.38` ein. Sofern eine Namensauflösung konfiguriert ist, kann man statt der IP-Adresse auch alternativ den [:Rechnername:Rechnernamen] oder eine Domain angeben, also z.B. {{{#!vorlage Befehl ssh user@sol-1 # weiteres Beispiel ssh user@example.com }}} Ist der Rechner, mit dem man sich verbinden will, erreichbar, sieht die Antwort z.B. so aus: {{{ pi@192.168.178.38's password: Linux minecraftpi 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l 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. Last login: Fri Oct 16 19:25:15 2020 from 192.168.178.37 }}} Als erstes wird das Passwort des Nutzers `pi` auf dem entfernten Rechner abgefragt. Nach erfolgreicher Eingabe ist man eingeloggt und befindet sich in einer interaktiven Shell. Die Angabe des Benutzernamens ist optional. Wenn man sich mit dem gleichen Benutzernamen wie auf dem lokalen Rechner anmelden will, lautet der Befehl {{{#!vorlage Befehl ssh 192.168.178.38 }}} das `pi@` kann entfallen. 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: {{{#!vorlage Befehl ssh pi@192.168.178.38 cat /etc/issue }}} {{{ pi@192.168.178.38's password: Raspbian GNU/Linux 10 \n \l }}} Oder etwas komplizierter - eine Datensicherung machen ("backup"): {{{#!vorlage Befehl ssh root@server 'cd /etc; tar czvf - network/' | cat > etc_network_backup.tar.gz }}} {{{ Password: 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 `-C` (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. Sollte die Verbindung nicht mehr reagieren, z.B. wenn der SSH-Server heruntergefahren wurde, lässt sich der SSH-Client mit der Eingabe von "`~.`" (nacheinander) beenden. {{{#!vorlage Hinweis Wer (noch) einen Windows-Desktop benutzt und über das SSH-Protokoll auf eine Linux-Maschine zugreifen will, kann das Programm [:PuTTY:] nutzen. }}} == SSH Host Fingerprint == Bei SSH gibt es im Gegensatz zu HTTPS gesicherten Webseiten keine zentralen Zertifikatsanbieter, die sicherstellen, dass man sich mit dem richtigen Server verbindet. In den meisten Fällen wird automatisch bei der Installation ein neuer Schlüssel generiert. Verbindet sich ein Client das erste mal mit diesem Server ist der angebotene Schlüssel noch unbekannt und man wird gefragt, ob man sich mit dem Server verbinden möchte. {{{#!vorlage Warnung Der Fingerprint stellt sicher, dass man sich nicht mit einem falschen Server verbindet. Einer der häufigsten Gründe für unbekannte Fingerprints ist die Neuinstallation eines Systems, bei dem neue Schlüssel generiert werden. Es kann jedoch auch ein "Man-in-the-Middle-Angriff" sein, bei dem die Verbindung auf einen anderen Server umgeleitet wurde. Aus diesem Grund muss der Fingerprint immer gegen eine vertrauenswürdige Quelle verglichen werden. }}} === Prüfen des Fingerprints === Beim ersten Verbindungsaufbau zu einem Server wird man gefragt, ob man sich mit dem Server verbinden möchte. {{{#!vorlage Befehl ssh github.com }}} {{{ The authenticity of host 'github.com (140.82.121.3)' can't be established. RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8. Are you sure you want to continue connecting (yes/no/[fingerprint])? }}} In diesem Fall möchte sich der SSH-Client mit Github.com verbinden und man wird gefragt, ob man mit dem Verbindungsaufbau weitermachen möchte. Diese Abfrage sollte man nicht einfach bestätigen, sondern den Fingerabruck mit einer vertrauenswürdigen Quelle vergleichen. Github hat die Fingerprints unter folgender Adresse veröffentlicht: [https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints] {en} Falls der SSH-Client die Möglichkeit bietet, einen Fingerprint einzugeben, ist diese Methode immer zu bevorzugen. Man muss dann nur den Fingerprint von der Webseite kopieren und im Terminal einfügen. Der Grund ist, dass es bei einem manuellen Vergleichen von Fingerprints zu Fehlern kommen kann und man einen ähnlichen Fingerprint bestätigt und sich mit dem falschen Server verbindet. {{{#!vorlage Warnung Sollte der Fingerprint unbekannt sein, muss man den Server-Administrator nach dem richtigen Fingerprint fragen. Bei einem gemieteten Server ist es auch möglich, den Support des Unternehmens zu kontaktieren. Man sollte sich jedoch nicht dazu verleiten lassen, einfach die Verbindung zu akzeptieren. }}} === Warnung bei geänderten Fingerprints === Bei allen weiteren Kontakten stellt das ssh-Programm jedoch von nun an über asymmetrische Kryptografie sicher, dass der Server auch über den richtigen privaten Schlüssel verfügt, der zum öffentlichen, in der Datei '''~/.ssh/known_hosts''' abgelegten passt, und verweigert im Zweifelsfall den Verbindungsaufbau. Hier eine Beispielausgabe: {{{ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:2iJAHZZHlYMrlrBGw3t7Ma62TuZ0p7p+av3O4W+cpHY. Please contact your system administrator. Add correct host key in /home/tux/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /home/tux/.ssh/known_hosts:6 remove with: ssh-keygen -f "/home/tux/.ssh/known_hosts" -R 172.217.22.227 ED25519 host key for 172.217.22.227 has changed and you have requested strict checking. Host key verification failed. }}} Es gibt mehrere Gründe für geänderte Fingerprints. Einer der häufigsten ist die Neuinstallation eines Systems. Jedoch kann dies auch ein Zeichen dafür sein, dass man sich mit einem falschen Server verbindet (MITM). Bei einer Warnung sollten man auf jeden Fall den Server-Administrator oder den Support kontaktieren und fragen, ob der Server neu installiert oder die Schlüssel neu generiert wurden. Sollte dies der Fall sein, muss man sich die aktuellen Fingerprints über eine vertrauenswürdige Quelle schriftlich zukommen lassen. Hat sich der Fingerprint aus einem legitimen Grund geändert, kann man den alten Fingerprint mit folgendem Befehl entfernen: {{{#!vorlage Befehl ssh-keygen -f -R }}} Im obigen Beispiel also {{{#!vorlage Befehl ssh-keygen -f "/home/tux/.ssh/known_hosts" -R 172.217.22.227 }}} [[Anker(Fingerprint_ueberpruefen)]] === Fingerprint des Servers ermitteln === Den Fingerprint nach einer Neuinstallation zu ermitteln, kann eine besondere Herausforderung sein. Dies trifft insbesondere für automatisch installierte Systeme zu. Falls es sich um eine virtuelle Maschine handelt, hat man oft die Möglichkeit, eine Terminal-Sitzung in der Administrationsoberfläche zu starten. Solche Administrationsoberflächen sind meist mittels HTTPS abgesichert und somit sollte die Verbindung vertrauenswürdig sein. Den Fingerprint eines Servers kann man anschließend in einem lokalen Terminal mit dem Systemprogramm '''ssh-keygen''' ermitteln. Als Format für die Fingerprints werden MD5 und SHA256 unterstützt. Aktuell wird immer mehr auf SHA256 gewechselt, jedoch sind vereinzelt auch noch MD5 Finperprints anzutreffen. Aus diesem Grund sollte man die Fingerprints in beiden Formaten ermitteln. {{{#!vorlage Befehl ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l -E md5 ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l -E sha256 }}} In den meisten Fällen werden mehrere Schlüssel für einen SSH-Server generiert. Folgender Einzeiler ermittelt die SHA256-Fingerprints für alle Schlüssel. {{{#!vorlage Befehl find /etc/ssh/ -name 'ssh_*.pub' -exec ssh-keygen -f {} -l -E sha256 \; }}} Analog dazu kann man auch die MD5-Fingerprints berechnen: {{{#!vorlage Befehl find /etc/ssh/ -name 'ssh_*.pub' -exec ssh-keygen -f {} -l -E md5 \; }}} === SSHFP Records - Der Fingerprint im DNS === Bei SSHFP Records handelt es sich im spezielle Einträge in der DNS Zone einer Domain. Somit ist eine Grundvoraussetzung, dass für den Server, mit dem man sich verbinden möchte, ein DNS-Name existiert. Eine weitere Voraussetzung ist, dass die DNS Zone mittels [wikipedia:Domain_Name_System_Security_Extensions:DNSSEC] geschützt ist.Ist die Zone nicht mittels DNSSEC geschützt, bringt ein SSHFP Record keinen Sicherheitsgewinn. ====Server Konfiguration==== Auf einem Server können die SSHFP Records mit folgendem Kommando erstellt werden: {{{#!vorlage Befehl ssh-keygen -r examplehost.example.org }}} {{{ examplehost.example.org IN SSHFP 1 1 d004948e1d359f2a267f03a599c3efe5d8285ae1 examplehost.example.org IN SSHFP 1 2 f94a95111db1158903bc23e61f75843d029f9d3edabfd74c200f201d4b80b330 examplehost.example.org IN SSHFP 3 1 3b355dc1e3a508e4594e7f8aa30d315d820eb602 examplehost.example.org IN SSHFP 3 2 cacc4090df702522c977ea5dac7bb5d64b9b0968ca63879cc821f8b2b4b099d7 examplehost.example.org IN SSHFP 4 1 4a1923a588b2426b6353699dfe9a69102fd5a29d examplehost.example.org IN SSHFP 4 2 67be5c3169884615436ec3068cb08d150466e1fae39c18cd4952d2594ad1d512 }}} Diese DNS Records können anschließend in der DNS Zone hinterlegt werden. Anschließend muss die Zonen-Datei neu signiert werden. Um zu prüfen, ob die neuen DNS Records funktionieren, kann mit dies mit dem Programm '''dig''' prüfen. Sollte dig noch nicht installiert sein, kann dies nachgeholt werden: {{{#!vorlage Paketinstallation dnsutils }}} Anschließend können die SSHFP Records für den neuen Server abgefragt werden: {{{#!vorlage Befehl dig SSHFP examplehost.example.org +short }}} ====Client Konfiguration==== Standardmäßig prüft der OpenSSH Client nicht den Fingerprint gegen einen SSHFP Record. Aus diesem Grund muss in der Konfigurationsdatei '''.ssh/config''' folgender Eintrag hinzugefügt werden: {{{ VerifyHostKeyDNS yes }}} Verbindet man sich anschließend zu dem neuen Server, muss der Fingerprint nicht mehr bestätigt werden. ====Problembehebung==== Sollte der SSH-Client dennoch nach einer Bestätigung verlangen, kann es daran liegen, dass DNSSEC nicht verwendet wird oder fehlerhaft konfiguriert wurde. {{{ The authenticity of host 'examplehost.example.org (192.0.2.123)' can't be established. ECDSA key fingerprint is SHA256:MH85JK0yq+JNl1lPKUlxit+dGFqWMS/MmohcINp/e9Q. Matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no/[fingerprint])? }}} In diesem Fall ist der Fingerprint weiterhin gegen eine vertrauenswürdige Quelle zu prüfen. Der Fingerprint, der im DNS hinterlegt ist, gilt in diesem Fall jedoch nicht mehr als vertrauenswürdig. Der Grund hierfür ist, dass durch eine fehlerhafte DNSSEC Konfiguration die Integrität der DNS Zone nicht mehr gewährleistet ist. [[Anker(PubKeys)]] == Public-Key-Authentifizierung == 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__ (Server). Der private Schlüssel befindet sich 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 Server verschlüsselt diesen Datenblock mit dem öffentlichen Schlüssel des Klienten und wenn der Klient diesen Chiffre mit dem zugehörigen privaten Schlüssel wieder entschlüsseln kann (wofür nötigenfalls die Passphrase abgefragt wird), ist die Identität des Benutzers bestätigt. #Ob das Schlüsselpaar jeweils zusammenpasst ist auch davon abhängig, unter was man lokal angemeldet ist, und auf #welchem Rechner: ändert sich eines von beiden, so passen privater und öffentlicher Schlüssel nicht mehr zusammen. Das bedeutet, der Public Key ist wiederverwertbar, d.h. man kann das gleiche Schlüsselpaar von einem lokalen Nutzer aus für den Login auf verschiedene Server verwenden. Dies klappt, da der lokale Login dabei immer gleich bleibt. Der Private Key wiederum ist __nicht__ übertragbar. Daher muss man für jeden einzelnen lokalen Benutzer, mit dem man sich einloggen möchte, ein neues Keypair erstellen; dies gilt auch, wenn der Benutzer der gleiche bleibt, aber der Computername sich ändert Damit man dieses Verfahren überhaupt verwenden kann, muss man sich zunächst mit Hilfe des Kommandozeilenprogramms `ssh-keygen` ein entsprechendes Schlüsselpaar auf dem __lokalen Client__ erzeugen. Dadurch entstehen zwei Dateien. Ein privater Schlüssel ('''id_rsa''') welcher auf dem lokalen System (Client) verbleibt und ein öffentlicher Schlüssel ('''id_rsa.pub''') welcher später auf den Server übertragen wird. {{{#!vorlage Befehl ssh-keygen -t rsa -b 4096 -C "user@server Server 1" }}} {{{ 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: SHA256:ombg5tzRN3RT6FMobtBS8TZF+vIQPmG4V/3ESUFw3mE user@server Server 1 The key's randomart image is: +--[ RSA 4096]----+ | | | | | | | + . | | S E | | . + + | | .o . o.| | o.oo. oo| | ==o.BO+| +-----------------+ }}} Der voreingestellte Dateiname ('''id_rsa''') kann einfach mit der Taste [[Vorlage(Tasten, Enter)]] 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. Der Kommentar 'benutzer@firma.de Server 1' wird sehr hilfreich wenn man mehr als einen Schlüssel erstellt, und später auseinander halten will, wer welchen Rechner steuern darf. Ohne Angabe des Kommentars wird der-benutzer@die-maschine (mustermann@mein-pc) angegeben. Die wiederkehrende Eingabe der Passphrase kann der Schlüsselmanager des Systems übernehmen. (ssh-agent, ssh-add, [:Seahorse:] ehem. [:GNOME_Schlüsselbund:], [:KGpg:], ...) Nun muss noch der öffentliche Schlüssel, zu erkennen an der Endung '''.pub''' ('''id_rsa.pub'''), auf dem Zielsystem (Server) deponiert werden. Dazu dient das Programm ssh-copy-id. Zu diesem Zeitpunkt muss die Authentifizierung per Passwort noch erlaubt sein (`PasswordAuthentication yes`): {{{#!vorlage Befehl 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. }}} {{{#!vorlage Hinweis Sollte man - warum auch immer - bei der Angabe des Dateinamens des Schlüssels die Endung '''.pub''' vergessen, so wird diese automatisch durch `ssh-copy-id` angehängt. Man kann also nie aus Versehen seinen privaten Schlüssel Namens '''id_rsa''' (ohne Endung '''.pub''') übertragen. }}} {{{#!vorlage Experten Wenn man die Sicherheit des Schlüssels weiter erhöhen möchte, benutzt man anstatt des rsa-Verschlüsselungsverfahrens die Eliptische Kurve ED25519. Jeder Desktoprechner mit aktuellem Betriebsystem kann damit umgehen, selbst der RasPi, nur platzbeengte Firmware oder sehr alte Systeme kennen die eliptische Kurve nicht. Der Schlüssel wird durch diesen Befehl erstellt: {{{#!vorlage Befehl ssh-keygen -t ed25519 [-a420] -f ~/.ssh/testkeydateiname [-N "Passphrase"] [-C "Kommentar zum Testkey"] \}}} Dabei wird durch -a die Anzahl der Runden/Schleifen bestimmt, die ohne Parameter 256 und maximal 420 beträgt. Übertragen wird der Public-Key mit dem Befehl ssh-copy-id ganz einfach: {{{#!vorlage Befehl ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server \}}} }}} {{{#!vorlage Hinweis Wenn man mit dem aktuellen puttygen unter Windows die Schlüsseldateien erstellt hat, kopiert man direkt aus puttygen den angezeigten Block in die `authorized_keys` hinein. Die Datei muss folgendermaßen aussehen: {{{ ssh-rsa rsa-pub-key Key Kommentar \}}} }}} 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: {{{#!vorlage Befehl cat id_rsa.pub | ssh user@server 'cat>> ~/.ssh/authorized_keys' }}} Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption `-i ~/pfad/dateiname` gesondert angegeben werden. Für die dauerhafte Nutzung empfiehlt sich ein Eintrag in der [#ssh-config ~/.ssh/config] mittels `IdentityFile`-Parameter. Anschließend kann man sich ohne Passwort anmelden: {{{#!vorlage Befehl 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: >"Agent admitted failure to sign using the key." In diesem Fall einfach `ssh-add` ausführen. {{{#!vorlage Befehl ssh-add }}} {{{ Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) }}} {{{#!vorlage 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 '''.ssh'''-Verzeichnis und `authorized_keys` nur für den Eigentümer Schreibrechte hat. Hintergrund ist wohl, die Gefahr zu verringern, dass `authorized_keys` 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, in der Datei '''/etc/ssh/sshd_config''' die Option {{{ PasswordAuthentication no }}} und optional auch die Optionen {{{ ChallengeResponseAuthentication no PermitRootLogin no }}} setzen und mit einem {{{#!vorlage Befehl sudo systemctl reload ssh }}} die Konfiguration neu einlesen lassen. Alternativ: Auf der Serverseite eingeben `sudo passwd -l USER`. Damit wird das Passwort nur für den ausgewählten Account USER gesperrt. {{{#!vorlage Hinweis Eine weitere Möglichkeit eine SSH-Verbindung zu einem entfernten System mit einem ausgetauschten Schlüssel herzustellen, ist die Verwendung von Hardwaretokens mit OpenPGP-Funktionalität, z.B. Nitrokeys, YubiKeys. Der private Schlüssel verbleibt gesichert auf dem Token und ein Zugriff darauf ist nur nach Eingabe eines PINs möglich. Der große Vorteil der Methode, der private Schlüssel wird nicht auf der Festplatte abgespeichert, sondern verbleibt ausschließlich auf dem gesicherten Hardwaretoken. Auch eine Passworteingabe ist bei diesem Anmeldeverfahren nicht mehr erforderlich, da im Hintergrund der Client mit dem entfernten System wie gehabt die Schlüssel austauscht. }}} == .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 }}} Nun braucht man nicht mehr {{{#!vorlage Befehl ssh MeinBenutzerName@123.456.789.0 -p980 }}} zu schreiben, es reicht nun ein kurzes {{{#!vorlage Befehl ssh test1 }}} für einen Verbindungsaufbau. ====Host mit Public-Key-Authentifizierung==== Auf einem System, mit dem man sich per Public-Key-Authentifizierung anmeldet, empfiehlt sich folgende Konfiguration. {{{ Host test1 HostName 123.456.789.0 User MeinBenutzerName Port 980 IdentityFile ~/.ssh/id_ed25519 IdentitiesOnly yes ForwardAgent no PreferredAuthentications publickey }}} In diesem Fall wird mit `IdentityFile` ein Schlüssel für die Anmeldung angegeben. Durch die zusätzliche Option `IdentitiesOnly` wird nur der angegebene Schlüssel verwendet. Der Grund ist, dass der SSH Client ohne diese Konfiguration alle öffentlichen Schlüssel der Reihe nach an den Server sendet, bis der Server einen bekannten Schlüssel gefunden hat. Erst danach wird der eigentliche Login-Prozess mittels Public-Key-Authentifizierung durchgeführt (siehe [https://datatracker.ietf.org/doc/html/rfc4252#page-8 RFC-4252] {en}) Mit der Option `PreferredAuthentications publickey` wird vom Client nur mehr Public-Key-uthentifizierung verwendet, auch wenn vom Server andere Authentifizierungsmethoden angeboten werden sollten. Der Grund für diese speziellen Konfigurationsoptionen ist, dass dadurch Man-in-the-Middle-Angriffe erschwert werden, falls man aus Versehen einen falschen Fingerprint akzeptiert hat oder ein Server kompromittiert wurde. Alle Parameter, die man verwenden kann, findet man unter [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config openbsd.org] {en} oder in der [:man:Manpage] von ssh_config. == Aufruf / wichtige Parameter == {{{#!vorlage Befehl ssh server.tld ###### aktueller Nutzer ssh nutzer@server.tld ###### anderer Nutzer ssh server.tld -i datei-mit-zugangsdaten.txt }}} * `-4` – nur über IPv4 * `-6` – nur über IPv6 * `-L` – '''L'''ink/[#SSH-Tunnel Port-Weiterleitung] * `-L` `[Lokale-Adresse:]port:Server:Server-Port` * `-L` `-L Lokaler-Anschluss:Server:Server-Port` * `-R` – '''r'''ückwärtige link/[#SSH-Tunnel Port-Weiterleitung] * `-R` `[Lokaler-Anschluss:]Lokaler-Port:Server:Server-Port` * `-R` `remote_socket:host:Server-Port` * `-R` `[Lokale-Adresse:]Lokaler-Port` * `-D` – `[Lokale-Adresse:]Lokaler-Port Server` – [#Dynamischer-Tunnel dynamische Port-Weiterleitung SOCKS4/SOCKS5] * `-J` – '''J'''ump - springt über einen/mehrere Komma/ta getrennte Server um Server hinter Router zu erreichen (über NAS zum Raspi) – [#Login-ueber-mehrere-Rechner Aktivierung im Zwischenserver] nötig! * `-N` – '''n'''o shell / nicht die Shell offen lassen * `-q` – '''q'''uiet / keine Fehlermeldungen zeigen * `-B` – '''b'''ind_interface (z.B. eth0) auf einen eigenen Netzwerkanschlus beschränken * `-b` – bind_address (z.B. 127.0.0.1) auf eine eigene Netzwerkadresse beschränken * `-E` – Logdatei führen, Log '''e'''xportieren * `-F` – '''F'''ile of config / Konfigurationsdatei einlesen anstatt Parameter in der Shell * `-f` – startet alles im Hintergrund (Befehle `fg/bg`) Das Beschränken auf einen Anschluss oder eine Adresse ist nur sinnvoll, wenn man mehrere davon hat (mehrere Netzwerkkarten oder mehrere IP-Adressen um von einem Klient in zwei Netzwerken/Netzwerksegmenten aktiv zu sein) oder bei Weiterleitungen, um den Zugriff zu beschränken. Alle Parameter, die man verwenden kann, findet man unter [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh_config openbsd.org] {en} oder in der [:man:Manpage] von ssh. [[Anker(SSH-Server)]] = Der SSH-Server = Im Gegensatz zum SSH-Klienten ist der SSH-Server unter Ubuntu standardmäßig nicht installiert. Er lässt sich über das Paket {{{#!vorlage Paketinstallation openssh-server }}} installieren. 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 [#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: {{{#!vorlage Befehl sudo service ssh restart }}} neugestartet werden, damit die Änderungen wirksam werden. Standardmäßig wird der SSH-Server beim Booten geladen. [:16.04:Ubuntu 16.04] und neuer verwendet für die Steuerung des Autostart [:systemd:] . == Identifikationsschlüssel übernehmen == Bei der Installation des SSH-Servers wird ein Satz Identifikationsschlüssel für das System (Fingerprints) erzeugt. Die entsprechenden Dateien lauten '''/etc/ssh/ssh_host*'''. Möchte man die Identifikationsschlüssel aus einem bestehenden System oder einer früheren Installation übernehmen, so muss man die oben genannten Dateien ersetzen. Sinnvoll ist dies z.B. im Rahmen einer Neuinstallation oder wenn man auf ein und dem selben Rechner mehrere Linux-Versionen installiert hat. Damit vermeidet man auf Client-Seite die Offending-Key-Problematik (siehe [#Offending-Keys Problembehebung]). == Schlüssel vom Server nahtlos wechseln == Wenn der SSH-Server schon eine Weile betrieben wird, kann es vorkommen, das inzwischen technisch unsichere Schlüssel wie zum Beispiel [wikipedia:Digital_Signature_Algorithm:DSA] benutzt wird, oder der private Schlüssel in Umlauf geraten ist. In diesem Fall kann man die Schlüssel mithilfe einer Übergangszeit austauschen, ohne auf das im vorigen Kapitel genannte Offending-Key Problem zu treffen. Hierfür gibt es eine wichtige Voraussetzung: Im Client muss in der SSH-Client-Konfigurationsdatei unter '''/etc/ssh/ssh_conf''' die Option: {{{ UpdateHostKeys yes }}} zu finden sein. Diese ist standardmäßig __nicht__ vorhanden und muss hinzugefügt werden. Auf Seiten des Servers muss mit dem folgenden Befehl ein neuer Schlüssel erstellt werden.: {{{#!vorlage Befehl sudo ssh-keygen -f ssh_host_ed25519_key_neu -t ed25519 }}} Anschließend muss man in der Datei '''/etc/ssh/sshd_conf''' die Zeilen: {{{ HostKey /etc/ssh/ssh_host_ecdsa_key # Alter Schlüssel (Standard) HostKey /etc/ssh/ssh_host_ed25519_key_neu # Neuer Schlüssel }}} hinzufügen. Nach einem Neustart des SSH-Servers durch: {{{#!vorlage Befehl sudo systemctl restart ssh }}} kann sich jeder Client, der die vorhin genannte Vorraussetzung erfüllt, immernoch einloggen und schreibt die so hinzugefügten Schlüssel in die Datei '''known_hosts''', um sie später zu verwenden. Wenn alle Clients sich einmal mit dem Server verbunden haben, kann die Zeile: {{{ HostKey /etc/ssh/ssh_host_ecdsa_key }}} auskommentiert werden und der Schlüsselaustausch ist beendet. {{{#!vorlage Experten Im Befehl `ssh-keygen` kann für den Parameter `-t`, zwischen verschiedenen Verschlüsselungstechniken ausgesucht werden. Es gibt folgende Möglichkeiten: * [wikipedia:Digital_Signature_Algorithm:DSA] - Völlig veraltert, sollte nicht verwendet werden! (Entworfen von der NSA) * [wikipedia:RSA-Kryptosystem:RSA] - Noch ausreichend, aber etwas langsam. * [wikipedia:Elliptic_Curve_DSA:ECDSA] - Verbesserung von DSA. Nun auf Basis elliptischer Kurven. (Standard) * [wikipedia:Curve25519#Ed25519_und_weitere_Kurven:ED25519] - Neue Verschlüsselungtechnik auf Basis ellipischer Kurven }}} = 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: {{{#!vorlage Befehl 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 [:cp:] bekannte Optionen, bspw. `-r` 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 `rsync -e ssh` genutzt werden (man beachte die Handbuchseite zu diesem Tool) oder der oben schon genutzte Trick mit tar und einer Pipe. {{{#!vorlage Befehl 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: {{{#!vorlage Befehl sftp server }}} {{{ 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 [: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 [:Nautilus:] unterstützt das SSH-Protokoll von Haus aus. Dazu benutzt man eine Adresse der Form `ssh://rechnername/pfad`, 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 `ssh://andererbenutzer@rechnername/pfad`. Alternativ können auch die Hosts aus der '''~/.ssh/config''' verwendet werden. Dort lassen sich auch noch andere SSH-Einstellung, wie. z.B SSH-Keys, definieren. Der Zugriff erfolgt mit `ssh://hostname`. Diese Adressen funktionieren übrigens auch in einigen anderen Gnome-Anwendungen. === KDE/Kubuntu === Auch bei KDE ist SSH-Unterstützung eingebaut: * Im Dateimananger [:Konqueror:] mann man mit einer Adresse der Form `fish://rechnername/pfad` auf die Dateien auf einem anderen Rechner zugreifen, und mit `fish://andererbenutzer@rechnername/pfad` meldet man sich als anderer Benutzer auf dem Zielrechner an. * Wie bei Konqueror funktioniert es auch in vielen KDE-Anwendungen. Man kann also beispielsweise im Malprogramm [: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 [: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. * Der Dateimanager [:Krusader:] erlaubt ebenfalls den Zugriff über SSH. ''"Unter Extras>Neue Netzwerkverbindung"'' kann man den Zugriff auf den SSH Server einrichten. Als Protokoll wählt man hier `sftp://`. === Xfce/Xubuntu === Der Xfce-Dateimanager [:Thunar:] unterstützt das SSH-Protokoll wie Nautilus unter GNOME. Siehe [:SSH#Gnome-Ubuntu:Gnome-Ubuntu]. === Weitere grafische Programme === Die meisten grafischen FTP-Clients ([:FTP:]) unterstützen auch sftp oder scp über das SSH-Protokoll. Beim Gnome FTP-Cient [: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 [#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 [:Unison:] und Backupprogramme wie Keep. == Verschlüsseltes Home-Verzeichnis == Man sollte darauf achten, dass bei verschlüsselten Home-Verzeichnissen (ecryptfs) auch die `authorized_keys` 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 `authorized_keys` in ein nicht-verschlüsseltes Verzeichnis zu legen (z.B. '''/etc/ssh/username/''') und die Einstellung `AuthorizedKeysFile` in der '''/etc/ssh/sshd_config''' auf `/etc/ssh/%u/authorized_keys` zu ändern (Root-Rechte und Neustart des SSH-Daemons erforderlich). {{{#!vorlage Befehl 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?] {en} [[Anker(SSH-Agent)]] == 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 `ssh-add`, wobei die Option `-l` die augenblicklich gespeicherten Schlüssel auflistet: {{{#!vorlage Befehl ssh-add -l }}} {{{ The agent has no identities. }}} {{{#!vorlage Befehl ssh-add }}} Wenn der SSH-Agent noch nicht gestartet ist (ggf. auf Servern ohne grafischen Desktop) wird folgende Meldung ausgegeben: {{{ Could not open a connection to your authentication agent. }}} Dann kann man den SSH-Agenten zunächst starten mit: {{{#!vorlage Befehl eval $(ssh-agent -s) }}} oder gleich mit dem Befehl zum Hinzufügen des Schlüssels: {{{#!vorlage Befehl eval $(ssh-agent -s) && ssh-add }}} {{{ Enter passphrase for /home/user/.ssh/id_rsa: Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa) }}} {{{#!vorlage Befehl 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) }}} {{{#!vorlage Befehl 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 {{{#!vorlage Befehl 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: {{{#!code shell if [ $SSH_AGENT_PID ]; then if [[ $(ssh-add -l) != *id_?sa* ]]; then ssh-add -t 2h ## Haltbarkeit von 2 Std. fi fi }}} Man kann aber auch in seiner lokalen Konfiguration '''$HOME/.ssh/config''' {{{ AddKeysToAgent yes }}} einfügen. Dann wird bei der ersten Ausführung von ssh der Schlüssel automatisch zum Agent hinzugefügt (ab openssh 7.2). == 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 `ssh-add` 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 [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 [:GNOME_Schlüsselbund:GNOME-Schlüsselbund] dann nicht mehr automatisch freigeschaltet wird. {{{#!vorlage Hinweis 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-[wikipedia:Runlevel:] oder von einer Live-CD starten. }}} = X-Forwarding = [[Bild(./screenshot_ssh_X-neu.png, 350, right, title="Auf einem lokalen Ubuntu 12.04 LTS wird via X-Forwarding das Mailprogramm eines entfernten Kubuntu 12.10 - Rechners angezeigt.")]] 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 `-X` (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 `-Y`, 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 `-x` (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: Gelegendlich wurde beim X-Forwarding Interoperabilitätsprobleme mit dem D-Bus beobachtet die eine ca 30 sekündige Startverzögerung bei einigen Programmen verursachen. Abhilfe ist im Artikel [:D-Bus:] beschrieben. * Öffnen des Programms [:Leafpad:]: {{{#!vorlage Befehl ssh -X user@server leafpad & }}} * Zur bequemeren Nutzung entfernter Programme können auch die Panel-Programme der jeweiligen Desktop-Umgebung gestartet werden, z.B. [:LXDE_Einstellungen#Panel:LXPanel], [:Xfce Panel:] und andere: {{{#!vorlage Befehl 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 [:xkill:] schließen. == Serverkonfiguration == {{{#!vorlage Hinweis Dies sollte in der Regel nicht notwendig sein. }}} Auf dem Server muss hierfür das Paket {{{#!vorlage Paketinstallation 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 `#` 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: {{{#!vorlage Befehl ssh -L [bind_address:]port:host:port user@server ssh -R [bind_address:]port:host:port user@server }}} Hierbei richtet die Option `-L` 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 `-L` bzw. `-R` gibt dabei die Richtung an, aus der der Tunnel benutzt werden kann. Bei `-L` vom eigenen Rechner zum entfernten hin, bei `-R` 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 '''*''' 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 `-N`, 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`: {{{#!vorlage Befehl 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 }}} {{{#!vorlage Befehl 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 `GatewayPorts` in der Server-Konfiguration entsprechend zu setzen, genaueres zu finden in der Manpage; man wähle diese Option mit Bedacht!): {{{#!vorlage Befehl 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: {{{#!vorlage Befehl 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: [[Bild(./ssh-tunnel-improved.png, align=center)]] Doppelter SSH-Tunnel über zwei Konsolen: [[Bild(./doppelter_ssh_tunnel.png, align=center)]] {{{#!vorlage Befehl supportpc$ ssh -L 54321:localhost:54321 zwischennutzer@zwischen zwischen$ ssh -L 54321:localhost:8080 zielnutzer@ziel }}} SSH-Tunnel über Zwischenrechner mit Zielrechner verbinden: [[Bild(./ssh_tunnel_zu_ziel.png, align=center)]] {{{#!vorlage Befehl supportpc$ ssh -L 54322:ziel:22 zwischennutzer@zwischen }}} = Dynamischer Tunnel = Der Dynamische Tunnel hat einen fixen Einstiegspunkt, hat einen dynamischen Ausgang und kann so als SOCKS4/5-Proxy Eingang genutzt werden. Beispiel: {{{#!vorlage Befehl ssh -D 8080 nutzer@zwischenserver.nett -N -q ssh -D [Lokale-Adresse:]Lokaler-Port Nutzer@Zwischenserver.TLD }}} == Beschreibung == Der Port 8080 kann dann hier als SOCKS4/5 Proxy im Browser/System angegeben werden um am "zwischenserver.nett" mit dem Benutzer "nutzer" (SSH-Schlüssel eingerichtet vorrausgesetzt) eine Verbinung aufzubauen, als würde man am "zwischenserver.nett" selbst sein, von dort aus Webseiten aufrufen. == Verwendung == Dies ist äußerst hilfreich, wenn man unsichere, ältere HTTP-Webserver hat, die man nicht absichern kann und hinter einer Firewall, eines Routers eingesperrt bleiben sollen, man aber so mit einem sicheren und verschlüsselten SSH-Verbindung über einen Zwischenserver erreichen kann/will. Wie z.B. Heimautomation, TV-Receivern, WLAN-Accesspoints, Clients im sicheren privaten Netz - abgegrenzt vom Gastnetz oder nochmals abgegrenzt vom "normalen" Netz zur Steigerung der Sicherheit. Die Parameter `-N` und `-q` dienen zum [N]ichtaktivieren der Shell und zur leisen Verbindung ([q]uiet), ohne Fehlermeldung. Dabei bleibt die Verbindung im Vordergrund und kann dann einfach mit [[Vorlage(Tasten, Strg+x)]] beendet werden. {{{#!vorlage Warnung Wenn der Port am Client von anderen Rechnern erreichbar ist, können auch Dritte diesen nutzen. Dies ist ein Sicherheitsrisiko. Deshalb sollte der Einsatz beschränkt sein. Ein dauerhafter Einsatz sollte mit einem [:VPN:] gelöst werden, jeder AVM/Fritz Router bietet einem durchschnittlichem Anwender einfache Möglichkeiten das durchzuführen. }}} Die Nutzung vom Proxy zur normalen Nutzung im Firefox-Browser kann mit FoxyProxy ([https://getfoxyproxy.org/ Homepage] / [https://addons.mozilla.org/de/firefox/addon/foxyproxy-standard mozilla.org ADD-ONS]) ganz einfach umgestellt werden. = Weitere 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 geschicktes Probieren herausfindet) kann die Verschlüsselung umkehren und den Klartext wieder extrahieren. Bekannte und bewährte Algorithmen wie TripleDES, AES und Twofish wurden so konzipiert, dass das Erraten des Schlüssels sehr aufwendig und damit teuer ist – selbst wenn eine verschlüsselte Nachricht auch entschlüsselt vorliegt. Das größte Problem bei der Benutzung von symmetrischer Verschlüsselung ist daher, den Schlüssel sicher zum Kommunikationspartner zu befördern. == Asymmetrische Verschlüsselung == Um dieses Problem der symmetrischen Verschlüsselung zu umgehen, gibt es andere Algorithmen, die das für eine erfolgreiche Ver- und Entschlüsselung nötige gemeinsame Geheimnis so verschleiern, dass man es öffentlich verteilen kann. Bei diesem Verfahren, "asymmetrische Verschlüsselung" genannt, wird nicht ein Schlüssel erzeugt, sondern ein Schlüsselpaar. Dieses hängt mathematisch voneinander ab, kann aber nur mit sehr viel Aufwand voneinander abgeleitet werden. Jeweils zwei zueinander passende Schlüssel wirken dabei genau entgegengesetzt: Was mit dem einen Schlüssel verschlüsselt wird, kann nur durch den anderen Schlüssel einfach wieder entschlüsselt werden. Der Sender und eventuelle Angreifer müssen dagegen für die Entschlüsselung aufwendige Rechnungen anstellen, die sehr viel Rechenzeit kosten würden. Dies ermöglicht es, einen der beiden Schlüssel öffentlich zur Verfügung zu stellen. Mit diesem kann man dann Sendungen 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 vom Besitzer des privaten Schlüssels kommt. Diese Anwendungsmöglichkeit nennt man "digitale Signatur". Der Umgang mit asymmetrischen Verschlüsselungsalgorithmen wie RSA oder DSA erfordert signifikant mehr Rechenleistung als der mit symmetrischen. Daher 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. = Problembehebung = == Offending Keys == Die Fehlermeldung {{{ Warning: the ECDSA host key for 'SERVER_IP' differs from the key for the IP address '123.123.123.123' Offending key for IP in /home/BENUTZER/.ssh/known_hosts:[mark]3[/mark] Matching host key in /home/BENUTZER/.ssh/known_hosts:1 Are you sure you want to continue connecting (yes/no)? yes }}} durch eine geänderte IP kann man durch den Einzeiler {{{#!vorlage Befehl sed -i '[mark]3[/mark]d' /home/BENUTZER/.ssh/known_hosts }}} beheben. Dadurch wird der betroffene Eintrag entfernt. == SSH Key wird abgelehnt == Bei einem Verbindungsaufbau kann folgende Meldung erscheinen: {{{ Unable to negotiate with 192.168.x.x port 22: no matching host key type found. Their offer: ssh-rsa }}} Dies kann nach dem Update im Jahr 2022 daran liegen, dass mit [https://www.openssh.com/txt/release-8.8 OpenSSH 8.8 die ssh-rsa/rsa-sha1 Authentifizierung deaktiviert wurde] {en}. Idealerweise kann bei den betroffenen Geräten, oft ältere Geräte die Dropbear benutzen, SSH aktualisiert werden. Ist dies nicht möglich, kann eine Ausnahme in der `~/.ssh/config` über die folgenden Zeilen definiert werden: {{{ HostKeyAlgorithms +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa }}} Dies sollte nur für die entsprechenden Hosts eingetragen werden: {{{ Host freifunk* User root HostKeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa }}} Weitere Informationen finden sich unter * [topic:ssh-problem-nach-update-auf-22-04-lts:SSH Problem nach Update auf 22.04 LTS] * [askubuntu:836048/ssh-returns-no-matching-host-key-type-found-their-offer-ssh-dss:] {en} == Unter sftp ist Zugriff auf alles ab dem Wurzelverzeichnis möglich == Bei der Nutzung von `sftp` erhält man Zugriff auf alles ab dem Wurzelverzeichnis ('''/'''). Dies sollte man aus Sicherheitsgründen einschränken. === Vorbereitung === Zuerst legt man eine Gruppe an, die später alle Benutzer beherbergen soll, denen nur der Dateitransfer per `sftp` erlaubt wird: {{{#!vorlage Befehl sudo addgroup exchangefiles }}} Dann werden ein root-Verzeichnis '''/home/exchangefiles''', in dem der Benutzer eingesperrt wird, und ein Depot-Verzeichnis '''/home/exchangefiles/files''' angelegt: {{{#!vorlage Befehl sudo mkdir -p /home/exchangefiles/files sudo chmod 755 /home/exchangefiles/ sudo chgrp -R exchangefiles /home/exchangefiles/ sudo chmod 1777 /home/exchangefiles/files/ }}} Wichtig: Die Verzeichnisberechtigung auf dem Root-Verzeichnis darf maximal `755` betragen. Ist die Berechtigung zu hoch (z.B. `777`), lässt `ssh` keine Client-Verbindungen herstellen: meist treten dann am Client Fehler wie "Konnte SFTP-Sitzung nicht initialisieren!" oder "Unable to startup channel" auf. Anschließend fügt man einen Benutzer hinzu: {{{#!vorlage Befehl sudo useradd -g exchangefiles -s /bin/false -d /home/exchangefiles hugo }}} Der Benutzer `hugo` erhält hierbei keinen Shell-Zugang (`/bin/false`). Dem Benutzer vergibt man im Anschluss noch ein Passwort: {{{#!vorlage Befehl sudo passwd hugo }}} === sshd-Konfiguration === Danach muss man die Konfiguration vom openssh-server wie folgt anpassen: {{{#!vorlage Befehl sudo vi /etc/ssh/sshd_config }}} Den bereits vorhandenen Eintrag: {{{ Subsystem sftp /usr/lib/openssh/sftp-server }}} ändert man wie folgt ab: {{{ Subsystem sftp internal-sftp }}} Und ganz am Ende der Datei '''/etc/ssh/sshd_config''' fügt man eine Sektion `Match Group exchangefiles` hinzu. Die darauf folgenden Regeln gelten für alle Benutzer der Gruppe `exchangefiles`. Statt `Group` kann man auch `User` für einen einzelnen Benutzer verwenden. So sehen dann die Veränderungen/Ergänzungen der Datei '''/etc/ssh/sshd_config''' aus: {{{ ###Subsystem sftp /usr/lib/openssh/sftp-server # Enable to built-in implementation of SFTP Subsystem sftp internal-sftp # This section must be placed at the very end of sshd_config Match Group exchangefiles # Force the connection to use the built-in SFTP support ForceCommand internal-sftp # Chroot the connection into the home directory of the user being authenticated ChrootDirectory %h # Disable network tunneling PermitTunnel no # Disable authentication agent forwarding AllowAgentForwarding no # Disable TCP connection forwarding AllowTcpForwarding no # Disable X11 remote desktop forwarding X11Forwarding no }}} Eine Beschreibung der einzelnen Begriffen kann man der `man sshd_config` entnehmen. Damit die Änderungen übernommen werden, muss der Dienst neu gestartet werden: {{{#!vorlage Befehl sudo service ssh restart }}} Hier im Beispiel hat der Benutzer mit dem Namen hugo nur noch einen SFTP-Zugriff auf alle Dateien und Verzeichnisse (Dateirechte beachten), die unter dem Verzeichnis '''/home/exchangefiles''' liegen - eine lokale Anmeldung ist verboten (`/bin/false`). Will man auf den SFTP/SSH-Server über das Internet zugreifen, so muss man im Router eine entsprechende [:Portweiterleitung:] einrichten, sonst kommt keine Verbindung zustande. Dabei kann man nach außen einen anderen Port als Standard (22) verwenden (z.B. 2017), ein geänderter Port kann Angriffe erschweren. === Test === Auf dem SSH-Client: {{{#!vorlage Befehl sftp -P 2017 hugo@server.example.com ssh -p 2017 hugo@server.example.com }}} Mit dem `sftp` soll eine Verbindung zustande kommen, aber `ssh` soll eine Fehlermeldung zurückbringen: {{{ Could not chdir to home directory /home/exchangefiles: No such file or directory This service allows sftp connections only. Connection to server.example.com closed. }}} Ist man verbunden, soll man in der Lage sein, die Dateien unter '''/home/exchangefiles/files''' aufzulisten, hochzuladen, herunterzuladen und zu löschen. = Links = == Intern == * [:Mosh:] - auf SSH aufsetzende Lösung für den Fernzugriff auf andere Rechner * [:fail2ban:] - unerlaubte Zugriffe via SSH blockieren * [:Portweiterleitung:] - DSL-Router für SSH freischalten * [:Screen:] - Fenstermanager zur Verwendung mit textbasierten Eingabefenstern (Textkonsole) und Wiederaufnahme abgebrochener ssh Verbindungen == Extern == * [http://www.ietf.org/rfc/rfc4251.txt The Secure Shell (SSH) Protocol Architecture] {en} * [youtube:Hxsl-jj2Bq0: Video] vom Vortrag Ubuntu im sicheren Netz - Ubucon 2011 {de} * [youtube:V-fhXawtQXQ?t=12m32s: Tunneling 101 – von überall ins Netz (SSH, Tinc, Socks, Krypto)] {de} - Vortrag Ubucon Berlin, 2015 * [http://thepcspy.com/read/making-ssh-secure/ Putting the Secure in SSH] {en} - Tipps und Tricks für sicheres SSH. Blogbeitrag, 11/2014 * [http://www.harding.motd.ca/autossh/ autossh] {en} - Monitor für SSH-Verbindungen mit Reconnect-Möglichkeit (in den Paketquellen enthalten) * [http://ctaas.de/linux-install.htm#OpenSSH-Server_SFTP-Server_Secure_Shell SFTP-Server Tutorial] {de} - Grundkonfiguration, Brute-Force-Angriffe erschweren, User in Verzeichnisse einsperren, Public-Key-Authentifizierung (Zugriff über Zertifikate) sowie einige Client Zugriffsmöglichkeiten * [http://github.com/ssh-mitm/ssh-mitm SSH-MITM - ssh audits made simple] {en} Audit Tool für SSH Verbindungen, das für Security Audits und Malware Analyse verwendet werden kann * [https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server Anleitung für SSH mit Schlüsselpaaren] {en} # tag: Sicherheit, Internet, Netzwerk, Server, System, Shell, ssh, Fernwartung