Installation und Absicherung von SSH unter Linux

Was ist ssh? SSH wird verwendet, um eine Verbindung zu einem anderen Rechner herzustellen. Unter Windows kennt man das unter Remote Control, unter Linux brauchen wir das nicht, da bei einem Linux Server (Root Server) in der Regel keine grafische Oberfläche installiert ist. Braucht man da in meinen Augen nicht wirklich. Erst recht nicht, wenn Ihr Zuhause seid und der Root Server in irgendeinem Rechenzentrum steht.

Die Frage, warum man ssh absichern sollte, sollte man sich eigentlich nicht fragen. Aber gut, den einen oder anderen wird es geben, der sich das fragen wird, daher gehe ich auf den Punkt nur kurz ein.

Dass gerade schlecht konfigurierte Server ein gefundenes Fressen für jeden Hacker sind, sollte eigentlich klar sein. 100 % Sicherheit gibt es zwar im Internet nicht, allerdings muss man es den bösen Jungs ja auch nicht gerade einfach machen. Daher machen wir dir Tür zwar nicht zu 100 % dicht, aber so schwer, dass man sich schon etwas anstrengen muss, um Sie zu öffnen.

Installation von ssh

Zunächst, bevor man was absichert, muss man es auch installieren. Allerdings, auf einem frischen Root Server in einem Rechenzentrum ist ssh in der Regel installiert. Somit können wir uns mit

ssh benuterzname@server_ip

verbinden und den Schritt der Installation überspringen.

Sollte auf unserem Rechner kein ssh installiert sein, geht es hier weiter:

apt install ssh -y 

in die Konsole genagelt. Als Root versteht sich.

Solltest Du eine andere Linux Distribution als Debian bzw. einen Debian Klon nutzen, dann entsprechend deiner Distribution installieren.

Da wir die Konfigurationsdatei ändern, machen wir mal eben ein Backup von der originalen

cp /etc/ssh//{sshd_config,sshd_config.orig}

Soweit so gut.

SSH erzeugt bei der Installation einen eigenen Key. Der ist zwar toll, aber wir machen unseren eigenen. Der ist auch stabiler als der automatisch generierte.

ssh-keygen -o -a 100 -t ed25519 -N "" -f /etc/ssh/ssh_host_ed25519_key -C "$(whoami)@$(hostname)-$(date -I)"

Was macht dieser Befehl genau?

In dieser Befehlskette sind ein paar Parameter verbaut. Erklärung in der eingegebenen Reihenfolge:

-o: Hier wird der erzeugte Key in dem neuen OpenSSH Format, was die Stabilität gegen Brute-Force-Attacken erhört.
-a: hier wird angegeben, wie viele Schlüsselfunktionen, sog. KDF (Key Derivation Function), bei der Schlüsselgenerierung genutzt werden sollen. Je höher man den Wert einstellt, dauert es zwar länger, aber es wird dadurch sicherer.
-t: Hier wird der Schlüsseltyp angegeben, mit der der Schlüssel erzeugt werden soll. Wir nehmen hier den aktuell besten Signaturalgorithmus ED25519 bzw. Curve25519.
-f: Festlegung des Schlüsselnamens und dessen Speicherort.
-C: Datum und der Name des erstellenden Users wird hier als Kommentar eingetragen.

Absicherung des SSH-Servers

Verschiedene auftauchende Begriffe erkläre ich im Anschluss an die Konfiguration. Daher öffnen wir die sshd_config:

nano /etc/ssh/sshd_config

Mittels STRG+W suchen wir dann die nachfolgenden Punkte und tragen das ein, was nachfolgend hier steht:

HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms curve25519-sha256@libssh.org
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
LogLevel INFO
SyslogFacility AUTHPRIV
MaxSessions 2
MaxAuthTries 3
StrictModes yes
LoginGraceTime 60
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication yes
IgnoreRhosts yes
PermitEmptyPasswords no
HostbasedAuthentication no
ChallengeResponseAuthentication no
TCPKeepAlive yes
ClientAliveCountMax 2
ClientAliveInterval 1800
UsePAM yes
Compression no
Banner none
DebianBanner yes
VersionAddendum none
PrintMotd no
PrintLastLog yes
PermitTunnel no
PermitUserRC no
PermitUserEnviroment no
GatewayPorts no
X11Forwarding No
AllowTCPForwarding no
AllowAgentForwarding no
KerberosOrLocalPassword no
KerberosAuthentification no
KerberosTicketCleanup yes
AuthorizedKeysFile   %h/.ssh/authorized_keys

UseDNS no
AcceptEnv LANG LC_*

Da man nicht immer auf den Webseiten suchen will, wo man die Konfiguration herhat, hier mal die sshd_config mit Dokumentation zum Download:

sshd_config

Ich habe diese Configuration selbst irgendwann mal irgendwo heruntergeladen und an meine Bedürfnisse angepasst.

Testen wir den Server

Um die sshd_config auf Fehler zu prüfen, tippen wir in die Konsole

/usr/sbin/sshd -t

Kommen keine Fehler, dann können wir den Dienst starten.

Unter Debian geben wir

systemctl restart sshd

ein und alles ist fein. Der sshd läuft nun mit unserer Konfiguration.

Über eine zweite Vebindung testen wir das ganze nun. Sollte die Verbindung sauber klappen, haben wir alles richtig gemacht.

Kleines Gimmick

Dazu geben wir auf dem entfernten Server in der Konsole

apt install neofetch -y

ein. Damit installieren wir das Tool neofetch, was uns Informationen über den Server liefert.

Dafür hämmern wir als root nachfolgenden Befehl in die Konsole

bash -c $'echo "neofetch" >> /etc/profile.d/mymotd.sh && chmod +x /etc/profile.d/mymotd.sh'