Wenn man einen Server hat, welcher frei im Internet erreichbar ist und man dort mal in die entsprechenden Logdateien schaut, ist man meist überrascht über die Anzahl der fehlgeschlagene Login-Versuche per SSH. Es gibt im Internet genügend gehackte Maschinen und bösartige Skripte, welche sämtliche SSH-Ports mit allen möglichen Benutzernamen/Passwort-Kombination bearbeiten die es gibt.
Um solche Login-Versuche zu erschweren kann man z.B. den SSH-Port ändern, aber das hilft auch nur bedingt.
Will man sich hier richtig sicher fühlen, so deaktiviert man die SSH-Authentifizierung per Passwort und verwendet statt dessen SSH-Keys.
einfache SSH-Keys
Hierbei wird asymmetrische Verschlüsselung genutzt, um den Benutzer zu authentifizieren. Der (oder die) öffentliche(n) Schlüssel des Benutzers befindet sich dabei in der Datei ~/.ssh/authorized_keys des Zielsystems, der private Schlüssel in einer Datei (meist id_rsa) im Verzeichnis ~/.ssh auf dem lokalen System, wo er zusätzlich von einer „pass phrase“ geschützt wird. Wenn man sich nun mit der Public-Key-Methode auf einem SSH-Server anmelden möchte, so schickt der Server dem Klienten eine zufällig generierte Challenge. Der 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.
Um ein entsprechendes Schlüsselpaar zu erstellen verwendet man:
ssh-keygen -b 4096 -t rsa -f ~/.ssh/id_rsa
-b 4096 gibt an, dass ein 4096 bit Schlüssel erstellt werden soll. Man kann auch größere Werte verwenden, aber die benötigen auch entsprechend mehr Ressourcen
-t rsa gibt an, dass ein RSA1 Schlüsselpaar erstellt wird
-f ~/.ssh/id_rsa gibt an, wo der private key gespeichert wird. Grundsätzlich kann man einen Speicherort seiner Wahl verwenden, aber man sollte darauf achten das der private key nur vom entsprechenden Benutzer-Account lesbar ist. Ansonsten weigert sich OpenSSH diesen zu verwenden.
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.
Wenn man die Sicherheit des Schlüssels weiter erhöhen möchte, benutzt man anstatt dem RSA Verschlüsselungsverfahren, die Eliptische Kurve ED255192.
Der Schlüssel wird durch diesen Befehl erstellt:
ssh-keygen -t ed25519
Beim erstellen des Schlüsselpaares wird eine kleine ASCII-Art angezeigt.
Bsp.:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
24:55:ee:67:83:72:82:55:5f:b9:b4:09:2a:fa:56:a1 user@client.local
The key's randomart image is:
+--[ RSA 4096]----+
| |
| |
| |
| + . |
| S E |
| . + + |
| .o . o.|
| o.oo. oo|
| ==o.BO+|
+-----------------+Falls man sich dieses später noch einmal anschauen möchte, so kann man den Befehl ssh-keygen -lv -f .ssh/id_rsa.pub verwenden
Soll diese „key’s randomart image“ bei jedem Login angezeigt werden, so trägt man in die lokale SSH Kofiguration unter ~/.ssh/config oder in die globale SSH Konfiguration unter /etc/ssh/ssh_config folgendes ein: VisualHostKey yes
Da das Schlüsselpaar generiert wurde, wird es nun Zeit den public key (nicht den private key!) auf dem gewünschten Ziel-System zu hinterlegen.
Sofern man bereits SSH-Zugang per Passwort hat, kann man folgenden Befehl verwenden: 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.Sollte ein SSH-Login per Keys dann nicht funktionieren, dann schaut man sich die Debugausgaben an die bei ssh -v 'user@server' ausgegeben werden.
Sollte ssh-copy-id nicht funktionieren, kann man den öffentlichen Schlüssel auch anders auf das Zielsystem kopieren und in die Datei ~/.ssh/authorized_keys einfügen. Dabei ist unbedingt darauf zu achten, dass die Datei mit der Endung .pub und nicht der private Schlüssel ohne diese Endung verwendet wird:
cat id_rsa.pub | ssh server 'cat>> ~/.ssh/authorized_keys'
Wenn ein vom Standard abweichender Dateiname für den Key gewählt wurde, muss er mittels der Kommandozeilenoption -i ~/pfad/dateiname gesondert angegeben werden.
Wenn nun alles geklappt hat und man sich erfolgreich per SSH-Keys einloggen konnte, so kann man nun eigentlich die Authentifizierung per Passwort komplett ausschalten.
Dazu sollten in der globalen SSH-Konfiguration unter /etc/sshd/sshd_config folgende Optionen angepasst werden:
Protocol 2
PermitRootLogin without-password
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM yesProtocol stellt hierbei sicher, dass nur Version 2 verwendet, da Version 1 veraltet ist und nicht mehr verwendet werden sollte3
PermitRootLogin dieses without-password ist etwas missverständlich, da es nicht bedeutet das man sich ohne jegliches Passwort als root anmelden kann, sondern es erlaubt root-Logins nur wenn etwas anderes als ein Passwort verwendet wird (z.B. public key authentication)
PubkeyAuthentication hier sollte unbedingt yes stehen, da man sich anschließend weder mit Passwort noch mit SSH-Keys einloggen kann
ChallengeResponseAuthentication sofern dies auf no gesetzt ist, werden auch andere nicht-SSH-Key-Logins (z.B. durch PAM) deaktiviert
PasswordAuthentication hier geschieht das eigentliche deaktivieren der Logins per Passwort
UsePAM Sofern PAM4 auf dem System eingesetzt wird ist es eine gute Idee hier ein yes einzutragen, da PAM auch Session und Account Management betreibt
Nun sollte der SSH-Dienst neu gestartet werden, z.B. mit: /etc/init.d/ssh restart oder systemctl restart sshd.service, etc…
1 https://de.wikipedia.org/wiki/RSA-Kryptosystem
2 https://de.wikipedia.org/wiki/Curve25519#Ed25519_und_weitere_Kurven
3 http://www.itwissen.info/SSH-secure-shell-SSH-Protokoll.html
4 https://www.pks.mpg.de/~mueller/docs/suse10.0/suselinux-manual_de/manual/cha.pam.html
