Im letzten Beitrag dieser Serie

Strato-V-Server mit Opensuse 12.3 – III – Stop SSH Root Login

hatten wir den SSH-Zugang über einen bereits verschobenen Port nur noch einem bestimmten unpriviligierten User [Bsp: “xtarjax”] zugestanden und den SSH-Zugang für root deaktiviert.

In diesem Beitrag ersetzen wir den normalen SSH-Login mit passwort-basierter Authentisierung durch eine Authentifizierung, bei der asymmetrische SSH-Schlüssel benutzt werden. Der Sicherheitsgewinn, den wir uns dadurch versprechen ist der, dass ein Login ab jetzt nur noch personalisiert und von Systemen aus möglich ist, auf denen

ein File mit dem privaten Schlüssel existiert,
eine Passphrase zur Aktivierung des Schlüssels bekannt ist.

Der verschobene SSH-Port ist dann auf dem Server zwar noch offen, aber ein Zugang geht nicht mehr von überall her und nicht mehr über die Angabe einer User-Id und eines Passworts. Wir zeigen die erforderlichen Schritte auf einem Linux-Client und dem Server.

Schlüsselgenerierung auf einem Opensuse-Client

Als normaler User erzeugen wir uns ein SSH-Schlüsselpaar mittels des Befehls “ssh-keygen”. Ohne Parameter aufgerufen, wird durch ssh-keygen ein RSA-Schlüsselpaar mit je 2048 Bit Länge für SSH2 erzeugt:

mysystem:~> ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/myself/.ssh/id_rsa): /home/myself/.ssh/id_rsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again: 
Your identification has been saved in /home/myself/.ssh/id_rsa.
Your public key has been saved in /home/myself/.ssh/id_rsa.pub.
The key fingerprint is:
77:1a:cb:72:6b:00:5a:22:7d:34:85:11:a4:5e:28:ea myself@mysystem.mydomain.de
The key's randomart image is:
+--[ RSA 2048]----+<br>
|         .++     |<br>
|         ....    |<br>
|        . +.     |<br>
|  .   .o o..     |<br>
|   o .o.S.       |<br>
|    +..*  .      |<br>
|    .+= S.      |<br>
|     oo..        |<br>
|     ...         |<br>
+-----------------+<br>
mysystem:~>

Bei höheren Ansprüchen kann man die Schlüssellänge (z.B. 4096 Bit) entsprechend vorgeben. Man benutzt dazu die Option “-b” (s. die man-Seite).

Hinweis 1:
Hat man bereits mehrere private SSH-Schlüssel für unterschiedliche Zwecke generiert, so muss man die Key-Files natürlich unter anderen Namen anlegen lassen, um ein Überschreiben des vorhandenen Keys zu vermeiden. Abweichende Namen setzen dann ggf. beim Aufnehmen der SSH-Verbindung die Option “-i” und die Angabe des richtigen privaten Key-Files voraus.

Hinweis 2:
Die Passphrase muss man sich unbedingt merken. Sie sollte hinreichend lang (deutlich länger als bei einem Passwort) sein und Sonderzeichen beinhalten. Von dieser Passphrase hängt die die Einsetzbarkeit und im Kompromittierungsfall auch die Sicherheit künftiger key-basierter SSH-Verbindungen ab. Die private Schlüssel-Datei wird mit dieser Passphrase verschlüsselt (!) im oben gewählten Verzeichnis hinterlegt. Ohne Kenntnis der Passphrase ist der Schlüssel nicht im Rahmen der SSH-Authentifizierung einsetzbar.

Kopieren des öffentlichen Schlüssels auf den Remote Server – hier den Strato-V-Server

Von einem anderen Terminalfenster loggen wir uns nun auf dem Strato-Server ein:

mysystem:~> ssh xtarjax@hxxxxxxx.stratoserver.net -p 6xxxx
xtarjax@hxxxxx:~>mkdir .ssh 
xtarjax@hxxxxx:~>cd .ssh
xtarjax@hxxxxx:~/.ssh>touch 600 
authorized_keys

Vom anderen lokalen Terminal kopieren wir nun das File mit dem öffentlichen (public) key auf den Server:

mysystem:~> scp -P 6xxxx ./.ssh/id_rsa.pub xtarjax@hxxxxx.stratoserver.net:/home/xtarjax/.ssh
Password: 
id_rsa.pub

Man beachte das großgeschriebene “P” in der Option für die Portangabe.

Wir wechseln wieder zu unserem Terminal mit der Remote-Verbindung:

xtarjax@hxxxxx:~/.ssh>cat id_rsa.pub >> authorized_keys
xtarjax@hxxxxx:~/.ssh>cat authorized_keys
xtarjax@hxxxxx:~/.ssh>rm id_rsa.pub
xtarjax@hxxxxx:~/.ssh>exit

Test der key-basierten Authentifizierung

Nun testen wir den Login mit den asymmetrischen Keys:

mysystem:~>ssh xtarjax@hxxxxxxx.stratoserver.net -p 6xxxx 
Enter passphrase for key '/home/myself/.ssh/id_rsa': 
Last login: Mon Nov  4 17:10:34 2013 from mysystem.mydomain.de
Have a lot of fun...
xtarjax@hxxxxxxx:~>

Bei der Rückfrage nach der Passphrase ist natürlich die Passphrase für den privaten Key anzugeben.

Hinweis:
Hat man einen von “id_rsa” abweichenden Namen bei der Generierung verwendet (oder mehrere private Key Files im Einsatz oder ein anderes verzeichnis zur Ablage gewählt) so muss man die Option “-i” verwenden:

mysystem:~>ssh xtarjax@hxxxxxxx.stratoserver.net -p 6xxxx  -i  PFAD/KEY_FILE 
Enter passphrase for key 'PFAD/KEY_FILE': 
Last login: Mon Nov  4 17:10:34 2013 from mysystem.mydomain.de
Have a lot of fun...
xtarjax@hxxxxxxx:~>

PFAD/KEY_FILE geben dabei den Pfad zu dem zu verwendenden File mit dem privaten SSH-Key an.

Wichtig – Sicherung der Keyfiles :
Auf unserem lokalen System sichern wir die generierten Schlüssel an einem sicheren (verschlüsselten) Ort. Es ist entscheidend, dass wir den privaten Key bei Bedarf aus einer gesicherten Datei rekonstruieren können. Sonst ist später je nach Einstellung für den SSH-Dämon ggf. kein Zugang mehr zum Server möglich.

Im lokalen “~/.ssh”-Verzeichnis können wir danach den public key auch löschen. Benötigt wird die Datei für den privaten Key. Die Rechte am entsprechenden File kontrollieren wir und setzen sie bei Abweichungen ggf. auf “600”.

Änderung der SSHD-Konfiguration auf dem Server

Hat der zertifikatsbasierte SSH-Zugang zum Server einwandfrei funktioniert, können wir nun die passwortbasierte Authentifizierung in der SSH-Konfiguration des Servers abschalten. Dazu editieren bzw. ergänzen wir als root die Datei “/etc/ssh/sshd_cofig” auf dem Server bzgl. folgender Einträge :

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys<br>
&
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

UsePAM no

Hinweis:
UsePAM kann man in der oben angegebenen Konfiguration auch auf “yes”setzen. Man beachte hierzu aber die Hinweise in der Datei:

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.

Wem das alles immer noch nicht reicht – oder wenn man seinen Usern hinsichtlich der Komplexität der selbst gewählten Passphrase für ihre Key-Dateien nicht traut – der kann zusätzlich ein Passwort setzen und dessen Eingabe verlangen. Dies geht dann mit

AuthenticationMethods publickey,password

in der sshd.conf. Siehe auch
https://access.redhat.com/site/ documentation/en-US/ Red_Hat_Enterprise_Linux/6/html/ Deployment_Guide/s2-ssh-configuration-keypairs.html

SSH unter Windows

Will man SSH von einem Windos-Client aus einsetzen, benutzt man das Opensource-Programm Putty – sowohl um Keys zu generieren als auch um die SSH-Verbindung auf dem Client zu parametrieren.

Achtung:
Ein direkter Einsatz einer ggf. auf einem Linux-Client erzeugten privaten SSH-Key-Datei – wie unsere obige “id_rsa”-Datei – ist unter PUTTY nicht möglich. Dennoch kann man die Datei verwenden: Das erfordert jedoch erst einen Import und dann ein Abspeichern in dem für PUTTY geeigneten Format. Man lese sich hierzu die ausführlichen Hilfeseiten von PUTTY durch.

ACHTUNG – Nachtrag Okt. 2016: Erheblich veränderte Sicherheitslage seit 2015

Diese kleine Artikelserie zur Einrichtung eines gehosteten Servers ist nun schon etwas älter. Wer meint, durch die obigen Maßnahmen bereits ein sicheres System zu haben, irrt deshalb. Durch die heutigen Möglichkeiten sind u.a. bestimmte Algorithmen der initialen Schlüsselbestimmung über das in SSH eingebaute Diffie-Hellman-Merkle-Verfahren nicht mehr als sicher einzustufen.

OpenSSH sollte daher unbedingt in der aktuellsten Variante 7.2p eingesetzt werden. Das entsprechende Paket findet sich im den SuSE “network”-Repository für aktuelle Opensuse Versionen (ab 13.1 bis Leap 42.2 und Tumbleweed). Siehe die Repos unter http://download.opensuse.org/ repositories/ network/

Zudem sollten auf dem Server in der “/etc/ssh/sshd_config” sowie auf den Client-Systemen in der “/etc/ssh/ssh_config” etliche weitere Einstellungen zur Härtung des SSH-Systems vorgenommen werden. Lesen Sie sich hierzu bitte den folgenden Artikel sorgfältig durch:
https://stribika.github.io/ 2015/01/04/ secure-secure-shell.html

Die meisten der dortigen Anweisungen sind einfach umzusetzen und schaden zumindest nicht, wenn man die Konfiguration der SSH-Clients unter seiner eigenen Kontrolle hat. Davon gehe ich bei gehosteten Servern aus.

Ich werde mich bemühen, an passender Stelle mal ein Update zu einer SSH-Konfiguration nachzuliefern, die aktuellen Anforderungen gerecht wird.