Nach oben

Alles zur Konfiguration von SSH

SSH oder Secure Shell bezeichnet ein kryptographisches Netzwerkprotokoll für den sicheren Betrieb von Netzwerkdiensten über ungesicherte Netzwerke.

Inhaltsverezeichnis


Einstellungen des Config auf dem Server

Für die Benutzung von SSH braucht es den SSH-Server und ein SSH-Client. Damit der Server sicher ist, muss dieser etwas speziell konfiguiert werden. Da zu verwendet man das /etc/ssh/sshd_config und trägt folgende Defintion ein:

Port 22
KexAlgorithms curve25519-sha256@libssh.org
Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
Ciphers chacha20-poly1305@openssh.com
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
UsePrivilegeSeparation yes
SyslogFacility AUTHPRIV
LogLevel VERBOSE
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
PubkeyAuthentication yes
AllowGroups ssh-user
HostbasedAuthentication no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
ClientAliveInterval 60
ClientAliveCountMax 10000
Banner /etc/ssh/sshd-banner
AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server


Entfernen der vorhandenen Schlüssel

Damit das ganze aber nun auch mit sicheren Schlüssel betrieben wird, sollten alle bisherigen Schlüssel auf dem server entfernt werden:

cd /etc/ssh/
sudo rm ssh_host_*key*

komplet ohne Rücksicht werden ALLE Schlüssel gelöscht, die brauchen wir nicht mehr - wir wollen ein Schlüssel und das ein sicherer, ohne irgendwelche Backdoors, ein sauberer ed25519.


Generieren eines neuen Schlüssels für den Server

Nun wird mit dem nachstehenden Befehl ein neuer Schlüssel (ed25519) für den Server generiert:

sudo ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null


Benutzer vorbereiten für den SSH-Zugriff

Erstellen der Gruppe ssh-user

Schlussendlich müssen wir noch eine Gruppe ssh-user definieren und die richtigen Benutzer darauf zuweisen:

# groupadd ssh-user

Benutzer der Gruppe ssh-user zuweisen

Damit SSH sicherer wird, müssen alle SSH-Benutzer in der Gruppe ssh-user angehören. Ein Benutzer kan wie folgt hinzugefügt werden:

# usermod -a -G ssh-user [username]

Benutzer aus einer Gruppe entfernen

Ab und zu kommt es vor, dass man ein Benutzer einer Gruppe entfernen muss. Dies kann mit folgendem Befehl ausgeführt werden:

# gpasswd --delete [username] [group]

Der SSH-Client

Die Erstellung eines sicheren Schlüssels

Für die Clients sollten nur sichere Schlüssel verwendet werden. Derzeit sollte man nur den curve25519 verwenden

ssh-keygen -o -a 100 -t ed25519 -C "$(hostname)-$(date +'%d-%m-%Y')"

Die Option “-a 100” besagt, dass der Schlüssel 100 Umdrehungen berechnen soll. 256 Umdrehugnen ist das maximum, ist aber nicht wirklich notwendig, da die Differnez zwischen 100 und 256 in der Berechnung der Umdrehungen nur noch in einem sehr kleinen Bereich sich ändert. Wird die Option weggelassen, werden 16 Umdrehungen berechnet, was für eine normale Sicherheit bereits genügt.

Eine Erstellung des Schlüssels kann wie folgt aussehen:

┌──(j√4d)-[~/.ssh]
└─$ ssh-keygen -o -a 256 -t ed25519 -C "$(hostname)-$(date +'%d-%m-%Y')"
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/j/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/j/.ssh/id_ed25519.
Your public key has been saved in /home/j/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:YgOLmuIwcDgfYhrjgkVtNM03q7qNu5Zno+g19LjOmhQ 4d-14-08-2021
The key's randomart image is:
+--[ED25519 256]--+
|    oo           |
|   o .o o        |
|  . +  . o       |
| o o o  .        |
|B.E o +.S        |
|*@ + +.o         |
|X.o +o.          |
|=o =+=+          |
| o=+XB..         |
+----[SHA256]-----+

In der Regel speichert man diese Ausgabe als Refernz in ein Textfile hostkey-gen.txt

Mit der generierung dieses Schlüssels werden 2 Files generiert:

Das File id_ed25519 ist der private Schlüssel und soll tunlichst immer sicher aufbewahrt werden!

Im File id_ed25519.pub befindet sich der öffentliche Schlüssel und kann an andere weitergegeben werden. Der Inhalt von id_ed25519.pub muss auf dem SSH-Server beim entsprechenden SSH-Benutzer in den Ordner in das File ~/.ssh/authorized_keys abgelegt werden.

Mein persönlicher öffentlicher Schlüssel sieht bspw. wie folgt aus: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJxRuFF1ncQ2MVwsAWkpWpM2CXYzoR1pry86n1SyfZN5 4d-14-08-2021

Die SSH Config

Für den Client kann ein File erstellt werden, in welchem er sich seine Verbindungen selbst konfigurieren kann. Ein config erleichtert den späteren Zugriff auf die unterschiedlichen SSH-Server. Das File muss im Homeverzeichnis des Benutzer im File ~/.ssh/config abgelegt werden. Der Inhalt des ~/.ssh/config sieht wie folgt aus:

Host jump
    Hostname 10.0.0.253
    User pi
    Port 22

Mit dieser Defintion kann später der Server jump mit dem Befehl

$ ssh jump

aufgerufen werden. Die SSH-Verbdinung wird nach dem Passwort des Zertifikates und allenfalls nach dem Passwort des Benutzers (je nachdem wie der Sever konfiguriert wurde) selbständig nachfragen. Wurde das Passwort des Zertifikates in einer Sitzung (unter Linux) einmal eingegeben, verweilt diese Information im Linux-System für die dauer der laufenden Session! Somit muss für alle anderen SSH-Aufrufe das Passwort für das Zertifikat nicht mehr eingegeben werden. Aus Sicht der Sicherheit ist dann nur noch der Server verantwortlich , indem er bspw. für den Benutzer noch speziell nach dem Passwort fragen kann (ist aber in seiner Konfiguration definiert).

Aufruf mit einem fremdem Schlüssel

Es ist möglich, dass man eine SSH-Verbindung mit einem fremdem Schlüssel aufruft - diese Situation kann auftreten, vor allem wenn man “früher” einmal ein Schlüssel für ein Server hatte und vergessen hat, sein neuer Schlüssel zu registrieren. Deshlab muss man nicht alles umstellen an seiner heutigen Defintion, sondern kann einfach den alten Schlüssel wie folgt einsetzen:

$ ssh -i ~/.ssh/old/id_ecdsa jump

Ebenso kann man das in seinem File ~/.ssh/config wie folgt angeben:

Host srvstation
    Hostname 10.0.3.90
    Port 10101
    User jc
    IdentityFile /home/it/.ssh/old/id_ecdsa

X11-Forwarding

Manchmal ist es sinnvoll, wenn man das X11-Forwarding aktiviert. Dies ist bspw. der Fall, wenn man sich zu einem SSH-Server verbindet, welcher in Wirklichkeit ein Client ist, d.h. über eine grafische Oberfläche verfügt. Nun will man bspw. dort ein Dateimanager (nautilus) grafisch aufrufen. Also braucht es für die SSH-Verbdinung Optionen die man mitgeben kann um dieses Ziel zu erreichen:

$ ssh -X -C jump

Mit der Option -X wir der X11 (grafische Ansicht) weitergeleitet. Die Option -C steht dann für die Kompression, damit es “schneller” geht um die grafische Information durch den SSH-Tunnel zu leiten werden die Informationen komprimiert.

Den SSH testen

Wird die Konfiguration geändert kann ein Test sehr hilfreich sein:

# sshd -t

Solltet ihr den Test nicht ausführen wollen, seid aber via SSH verbunden und habt an der Konfiguration Änderungen vorgenommen. Wenn es schief geht, werde ihr dann anschliessend euch auf eine Reise zum Server vor Ort begegeben, da ihr ansonsten kein Zugriff mehr habt. Also macht es Sinn, ein Test der Konfiguration durchzuführen.