News Ticker

Sicherheit: SSH-Benutzer-Identitäten

Ich selbst bin eine Person, die täglich mehrmals das SSH-Protokoll benutzt. Ob unter Linux mit dem openssh-Paket oder unter Windows mit PuTTY oder anderen Programmen. SSH (was übrigens für secure shell steht) ist verschlüsselt und damit sicher und telnet und ähnlichen Protokollen, die Benutzernamen, Passwörter und sogar den ganzen Inhalt unveschlüsselt übertragen, vorzuziehen. Nun ist es ein universelles Gesetz der Sicherheit, dass eine Kette nur so stark ist wie ihr schwächstes Glied - und das ist meistens der Benutzer. Dieser Artikel erfordert ein wenig Wissen im Umgang mit Linux, jedoch nicht sehr viel. Er soll außerdem mehr Denkanreize als fertige Lösungen geben, da nur ein angepasstes Sicherheitssystem ein gutes ist.

Das Ziel dieses Artikels ist es, die Sicherheit hinter Passwörtern etwas genauer zu erklären. Die meisten von uns benutzen statische Passwörter als Resultat einer synchronen Verschlüsselung. Das heißt im Klartext: Ich gebe das richtige Passwort ein und ich bin angemeldet. Dieses Prinzip ist, genauer betrachtet, sehr unsicher. Viele von uns schreiben sich das Passwort auf einen kleinen Zettel und legen es unter den Bildschirm etc. Andere wiederum benutzen zu einfache Passwörter wie KFZ-Kennzeichen, Geburtstage, Namen u.A. Wie also kann man die Passwortsicherheit verbessern? Und noch wichtiger: wie soll das in der Praxis aussehen?

Theoretisch ersetzt man das statische Passwort und die synchrone Verschlüsselung mit einer asynchronen. Man erstellt Schlüsseldateien welche gebündelt mit einem so genannten Passphrase benutzt werden müssen. Dies soll an einem typischen Anwendungsbeispiel, SSH, erklärt werden. Als erstes müssen die beiden Schlüssel erzeugt werden:

1
2
3
4
5
6
7
8
9
10
11
[martin@partners3 martin]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/martin/.ssh/id_rsa):
Created directory '/home/martin/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/martin/.ssh/id_rsa.
Your public key has been saved in /home/martin/.ssh/id_rsa.pub.
The key fingerprint is:
ef:70:53:f5:92:29:71:95:d5:ea:af:0e:b0:11:21:a4 martin@partners3.100mwh.com
[martin@partners3 martin]$

Nun wurden die Schlüssel erstellt und ich kann mir diese anschauen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[martin@partners3 .ssh]$ ls -l
total 8
-rw-------    1 martin   martin        951 Sep  2 05:17 id_rsa
-rw-r--r--    1 martin   martin        237 Sep  2 05:17 id_rsa.pub
[martin@partners3 .ssh]$ cat id_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,BC6D31A5F2D6697F
 
tSKu1zKrNax1+XUzcTl2DyLeCFhkI508nUl5oLXeEc8AdFyM/YsKRLJ9he1x2gIr
F170lrLF0bN8iBWoDkQMB5ElMNPJLt9lY4izF4GH1DQHOO/zImUBCRMkPRIGG5y+
uDJNgeo+Fy+lCuXRJ5HnE5GCng4z/LUT8nokXgRbCsPXNh3iBjwJkQgDa1XLNTKI
djXvZE9+pv2jp5uR0tODdc3V5vuVQEJ56wg9RSwttY5VO9v3Mw/nA+oXBf8rk7r6
yw1LBs7fjz4Xi8rDgdKBf37yZy0J9CHTa2Kp5tKI94FoqMrk8EYDQCHLy92Iw4tH
vVelnYNrdbImE6jLvYe5rZLz0RpPLw31FPUIyzDzonU8jvoP3gCCAoPl1rze6be8
4/4fghbvt3hnwPsI+XGVe8DQELedvxJAO1i5vyltqItumFLz7p1Y6YSa+P/BH8Vy
g/mCLWjVFQUJXpxPB4X7WicVEngJgmSR4vpQOacstQjNxJ3Q8P+KOZThWrqsMhW8
p3Jk54sPRg7JAcHGoR2KKWplRniYGZ5qnCRWzc9CrwVjMAlDc9SiWCgb37dQExEE
/0LUFh7ixA/KWKGz5RMgxszj/MEmxT4DD7IF0ER0zaFDIIME4tvLfBGkB/NE8+H1
uRlNph8WImfS6r3dVNYH0dQ/gcc6Yb4tlwQSkDxz5QoFUUHfkqxqDD9u5MCWqsiE
QEtehqr/KH3lePm7J6l+ItloY1wARncDGqJffAdJFOFaGijZ1yWR0pGz+XwhxZnG
LB0dp9j7765x6kcWIv8RTBJ15StBQlWWZt1GisbEilI=
-----END RSA PRIVATE KEY-----
[martin@partners3 .ssh]$ cat id_rsa.pub
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAv6rMciCtCMVBEnLPwNrjFWqq849p/x2ZfCCsLlaDKevmwmWYOUfyb/Qp7dSF8Mw02z5JDZ5RT8WJguWyM5Drlz74zsmyYIH9pkq4ijWYRB/BEv9+Pq5+3jptcGTQK/KM9Rp3vuP7ikfQujmUot1Jp1kfk9bGYBrlSZY8z6Cyuc8= martin@partners3.100mwh.com
[martin@partners3 .ssh]$

Die Schlüssel sind jetzt bereits voll funktionsfähig, aber um sicher zu stellen, dass der Server diese auch akzeptiert, müssen noch folgende Werte überprüft und evtl. gesetzt werden. Dies wird in der sshd_config nachgeschaut, normalerweise liegt diese in /etc/ssh/:

1
2
3
4
5
6
7
8
# SSH, Version 1 aktivieren
RSAAuthentication yes
 
# SSH, Version 2 aktivieren
PubkeyAuthentication yes
 
# Name der Datei, welche die öffentlichen Schlüssel beinhaltet
AuthorizedKeysFile .ssh/authorized_keys

Alles was jetzt noch erledigt werden muss, ist den öffentlichen Schlüssel in eine Datei diesen Namens auf dem Server zu kopieren.

1
2
3
4
5
6
7
8
[martin@partners3 martin]$ scp -P 2222 .ssh/id_rsa.pub tcr@ssh.blinkenshell.org:~/.ssh/authorized_keys
The authenticity of host 'ssh.blinkenshell.org (91.90.25.100)' cannot be established.
RSA key fingerprint is de:58:ea:93:0d:89:c1:d3:28:e2:cc:90:0c:bc:26:af.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'ssh.blinkenshell.org,91.90.25.100' (RSA) to the list of known hosts.
Password:
id_rsa.pub                                        100%  237     1.9MB/s   00:00
[martin@partners3 martin]$

Wenn man sich jetzt mit dem gleichen Server via SSH verbinden will, wird zuerst nach dem öffentlichen Schlüssel gesucht. Wird dieser gefunden, muss man das Passwort für diesen (und nicht das Benutzer-Passwort ) eingeben:

1
2
3
4
5
6
[martin@partners3 martin]$ ssh -p 2222 tcr@ssh.blinkenshell.org
Enter passphrase for key '/home/martin/.ssh/id_rsa':
Last login: Thu Sep  2 13:25:07 CEST 2010 from partners3.100mwh.com on ssh
System status:
 13:28:07 up 1 day, 13:13, 43 users,  load average: 0.04, 0.04, 0.00
tcr@triton ~ $

Am Ende noch ein paar kleine Tipps:

  • Benutzt man diese Methode, kann man die normale „keyboard-interactive“-Anmeldung gänzlich deaktivieren. Dies bedeutet, dass man sich ohne eine entsprechende Datei gar nicht anmelden kann
  • Verwendet man nur SSH, Version 2, kann man die Anmeldefunktion für Version 1 getrost abschalten.
  • Die Dateirechte der wichtigen SSH-Dateien sollten entsprechend restriktiv gesetzt sein, d.h. 0700 für ~/.ssh und 0600 für ~/.ssh/authorized_keys
  • Benutzt man mehrere öffentliche Schlüssel, kann man SSH mit dem Schalten -i und der entsprechenden Schlüsseldatei starten.
  • Ältere Versionen von SSH suchen oft nach einer Datei namens authorized_keys2. Man kann der Rückwärtskompabilität wegen einen symbolischen Link darauf setzen.

Ich hoffe der Artikel hat etwas zum Nachdenken angeregt. Für Vorschläge, Tipps und Fragen zu diesem Artikel bin ich natürlich offen, einfach einen Kommentar schreiben. Viel Spaß beim Ausprobieren!