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.

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])?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    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.

ssh-keygen -f <DATEI> -R <HOST> 

ssh-keygen -f "/home/tux/.ssh/known_hosts" -R 172.217.22.227 

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 

find /etc/ssh/ -name 'ssh_*.pub' -exec ssh-keygen -f {} -l -E sha256 \; 

find /etc/ssh/ -name 'ssh_*.pub' -exec ssh-keygen -f {} -l -E md5 \; 

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

sudo apt-get install dnsutils 

dig SSHFP examplehost.example.org +short 

VerifyHostKeyDNS yes

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])?

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.

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.

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 ⏎ 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):

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.

ssh-keygen -t ed25519 [-a420] -f ~/.ssh/testkeydateiname [-N "Passphrase"] [-C "Kommentar zum Testkey"] 

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server 

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:

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 mittels IdentityFile-Parameter.

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:

"Agent admitted failure to sign using the key."

In diesem Fall einfach ssh-add ausführen.

ssh-add 

Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

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

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.

.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

ssh MeinBenutzerName@123.456.789.0 -p980 

zu schreiben, es reicht nun ein kurzes

ssh test1 

für einen Verbindungsaufbau.

Host test1
    HostName 123.456.789.0
    User MeinBenutzerName
    Port 980
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes
    ForwardAgent no
    PreferredAuthentications publickey

Aufruf / wichtige Parameter¶

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 – Link/Port-Weiterleitung

  • -L [Lokale-Adresse:]port:Server:Server-Port

  • -L -L Lokaler-Anschluss:Server:Server-Port

• -R – rückwärtige link/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 – dynamische Port-Weiterleitung SOCKS4/SOCKS5

• -J – Jump - springt über einen/mehrere Komma/ta getrennte Server um Server hinter Router zu erreichen (über NAS zum Raspi) – Aktivierung im Zwischenserver nötig!

• -N – no shell / nicht die Shell offen lassen

• -q – quiet / keine Fehlermeldungen zeigen

• -B – bind_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 exportieren

• -F – File 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 openbsd.org 🇬🇧 oder in der Manpage von ssh.

⚓︎

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 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 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.:

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:

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.

Transfer von der Kommandozeile¶

scp benutzerx@server1:datei1 datei2 benutzery@server2: 

ssh root@server 'cd verzeichnis; tar czvf - verz./dateien' | tar xzf - 

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

Entfernte Dateisysteme einbinden¶

Man kann das Dateisystem eines entfernten Rechners in sein eigenes Dateisystem mittels sshfs einbinden. Damit ist eine transparente Nutzung von Dateien auch über unsichere Netze hinweg möglich.

Grafische Programme zum Dateitransfer¶

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).

sudo mkdir /etc/ssh/$USER
sudo mv $HOME/.ssh/authorized_keys /etc/ssh/$USER/
ln -s /etc/ssh/$USER/authorized_keys $HOME/.ssh/ 

Quelle: 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 ssh-add, wobei die Option -l die augenblicklich gespeicherten Schlüssel auflistet:

ssh-add -l 

The agent has no identities.

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:

eval $(ssh-agent -s) 

oder gleich mit dem Befehl zum Hinzufügen des Schlüssels:

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)

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:

1
2
3
4
5

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 dann nicht mehr automatisch freigeschaltet wird.

Serverkonfiguration¶

Auf dem Server muss hierfür das Paket

• xauth

Befehl zum Installieren der Pakete:

sudo apt-get install xauth 

Oder mit apturl installieren, Link: apt://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.

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 GatewayPorts 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 

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 Strg + X beendet werden.

Die Nutzung vom Proxy zur normalen Nutzung im Firefox-Browser kann mit FoxyProxy (Homepage / mozilla.org ADD-ONS) ganz einfach umgestellt werden.

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.

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:3
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

sed -i '3d' /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 OpenSSH 8.8 die ssh-rsa/rsa-sha1 Authentifizierung deaktiviert wurde 🇬🇧.

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

• SSH Problem nach Update auf 22.04 LTS

• 836048/ssh-returns-no-matching-host-key-type-found-their-offer-ssh-dss 🇬🇧

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.

sudo addgroup exchangefiles 

sudo mkdir -p /home/exchangefiles/files
sudo chmod 755 /home/exchangefiles/
sudo chgrp -R exchangefiles /home/exchangefiles/
sudo chmod 1777 /home/exchangefiles/files/ 

sudo useradd -g exchangefiles -s /bin/false -d /home/exchangefiles hugo 

sudo passwd hugo 

sudo vi /etc/ssh/sshd_config 

Subsystem sftp /usr/lib/openssh/sftp-server

Subsystem sftp internal-sftp

###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

sudo service ssh restart 

sftp -P 2017 hugo@server.example.com
ssh -p 2017 hugo@server.example.com 

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.

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¶

• The Secure Shell (SSH) Protocol Architecture 🇬🇧

• Video vom Vortrag Ubuntu im sicheren Netz - Ubucon 2011 🇩🇪

• Tunneling 101 – von überall ins Netz (SSH, Tinc, Socks, Krypto) 🇩🇪 - Vortrag Ubucon Berlin, 2015

• Putting the Secure in SSH 🇬🇧 - Tipps und Tricks für sicheres SSH. Blogbeitrag, 11/2014

• autossh 🇬🇧 - Monitor für SSH-Verbindungen mit Reconnect-Möglichkeit (in den Paketquellen enthalten)

• SFTP-Server Tutorial 🇩🇪 - Grundkonfiguration, Brute-Force-Angriffe erschweren, User in Verzeichnisse einsperren, Public-Key-Authentifizierung (Zugriff über Zertifikate) sowie einige Client Zugriffsmöglichkeiten

• SSH-MITM - ssh audits made simple 🇬🇧 Audit Tool für SSH Verbindungen, das für Security Audits und Malware Analyse verwendet werden kann

• Anleitung für SSH mit Schlüsselpaaren 🇬🇧