OpenSSH Public Key Authentifizierung unter Ubuntu

Aus Thomas-Krenn-Wiki
Wechseln zu: Navigation, Suche

Dieser Artikel zeigt, wie ein SSH-Zugang für eine Authentifizierung mittels Public-Key-Verfahren konfiguriert wird. Dazu wird am Client ein Schlüsselpaar erstellt, der öffentliche Teil der Schlüssel auf den Server übertragen und anschließend der Server für die Schlüssel-Authentifizierung eingerichtet. Der Benutzer kann sich dadurch ohne Login-Passwort am Server anmelden, es wird ausschließlich das Passwort zum Schutz des privaten Schlüssels benötigt. Die verwendeten Betriebssysteme in diesem Artikel sind einerseits ein Ubuntu 12.10 am Client und andererseits ein Ubuntu 12.04 am Server. Die Anleitung wurde ebenso unter Ubuntu 16.04 als Client und Server geprüft.

Am Client

Schlüsselpaar generieren

Im ersten Schritt wird am Client ein Schlüsselpaar mit ssh-keygen erstellt. Für die RSA-Schlüssel wird eine Bitlänge von 4096 Bit ausgewählt:

:~$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/gschoenb/.ssh/id_rsa): /home/gschoenb/.ssh/key_rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/gschoenb/.ssh/key_rsa.
Your public key has been saved in /home/gschoenb/.ssh/key_rsa.pub.
The key fingerprint is:
20:69:c5:c3:e2:2d:a8:09:49:b9:d9:ee:ca:f9:45:5e gschoenb@gschoenb-X220
The key's randomart image is:
+--[ RSA 4096]----+
|  .  o.          |
| o  .o+          |
|..+o+o..         |
|oo.oo...         |
|.o.  o ES        |
|o  .o .          |
|  .  o           |
|. ...            |
| +o.             |
+-----------------+
:~$ ls .ssh/
id_rsa  id_rsa.pub  key_rsa  key_rsa.pub  known_hosts  known_hosts.old

Achtung: Es wird aus sicherheitstechnischen Gründen empfohlen, den Schlüssel auf jeden Fall mit einer Passphrase zu schützen. Dadurch liegt der Schlüssel nicht im Klartext vor, sondern ist AES-CBC verschlüsselt:

:~$ cat .ssh/key_rsa
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,426FD49B9F6277AC00D62B08547D5FDE
[...]

Sollte der private Schlüssel von einem Angreifer gestohlen werden, muss dieser, um mit dem Schlüssel auf den Server zugreifen zu können, noch das Passwort des Schlüssels herausfinden. Beim einem Schlüssel, der im Klartext vorliegt, kann ein Angreifer mit einem gestohlenen Schlüssel direkt auf den Server zugreifen.

Öffentl. Schlüssel auf Server übertragen

Für das Übertragen des öffentlichen Schlüssels auf den Server wird im ersten Schritt noch die SSH-Verbindung mittels Passwort-Authentifizierung genutzt. Das Werkzeug ssh-copy-id kopiert das entsprechende Idendity-File auf den Server:

:~$ ssh-copy-id -i .ssh/key_rsa.pub tktest@192.168.56.101
tktest@192.168.56.101's password: 
Now try logging into the machine, with "ssh 'tktest@192.168.56.101'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

Das oben genannte Prozedere hat am Server in der Datei /home/tktest/.ssh/authorized_keys folgenden Eintrag erstellt:

:~$ cat .ssh/authorized_keys 
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC7qmegDxzv1omqG2cWM+i+qaEGzCoSBwqCeXyGUU93sTqtNYYHJVGj6YZqXeXEGzJtKm2A/uo59Y+WmqhJgW7HcT2Hqvo80NfbIRhqE9TJETyBe
GiiC8qpiYgPC2zigCNvTsRXh0CH5FJ1qy4QEBjztQDWOqSrsoOSJEEWCJiKJizTiXDmlGdiKE409GBo8lvlbMRWbrMj3iX825WTqy/T0Pio1kqANDotLnPA0sRXUPVyzc/ghzqRHzFetzP9j7C0nh
EvjiJphiuYvhbgix79FrCQG0lXBGcAWzsWUeAoT/d3kQu79+UTWxm+z4pnJ7gkKVMejqrWys560SdAqD264dc5UBRGI9j6XxVKdraSaEitDneONrSAt2tE/RwRxh2ASxqQfdF88zyDI8/ma608tHc
FROaNsn5hF+/wzjRK9akdhp5WjA5HXhg2OlkwKvSMhGlSgotRj5pr4Ebxjegysy1mEWRFN/vh/oNq4uHQy8adpfogaVELkI/Z2nuAdQk+uMy6D1hrKhUWubmBPxTbG00IWF25Tyuz8hnFRP9+gB/P
NRlF59/EHy27a72nirvuOyfxKnx/Mn+FD9Ah59OSLhWuo3sN9Im8yc2cliecwMz+DmTtE7TwzNw9v2zfxU9JDQwyLtppULiGpmKFOLHjz+SVGxSbVsWS//IyNK1GrQ== gschoenb@gschoenb-X220

Testen der Key-Authentifizierung

Nachdem sich nun der öffentlich. Schlüssel am Server befindet, kann vom Client aus die Verbindung getestet werden. Wichtig ist dabei, dass nicht nach dem Passwort des Benutzers am Server gefragt wird, sondern die Passphrase, mit der der Schlüssel geschützt ist, verlangt wird!

:~$ ssh -i .ssh/key_rsa tktest@192.168.56.101

Daraufhin erscheint bei GUI-basierten Systemen die folgende Dialog-Box:

OpenSSH-Public-Key-Dialog.png

Nach Eingabe des Passworts, mit dem der Schlüssel beim Erstellen geschützt wurde, ist man am System authentifiziert:

:~$ ssh -i .ssh/key_rsa tktest@192.168.56.101
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-23-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

  System information as of Thu Jan 17 13:51:19 CET 2013
[...]

Am Server

sshd-Konfiguration

Grundsätzlich genügt es unter Ubuntu, das oben angeführte Prozedere für die Public-Key-Authentifizierung durchzuführen. In manchen Situationen macht es dann auch Sinn, Passwort-Authentifizierung komplett zu deaktivieren.

Achtung: Nach Änderung der folgenden Einstellung, ist es nicht mehr möglich, sich mit einem Passwort über ssh anzumelden: PasswordAuthentication no.

:~$ sudo diff /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
51c51
< PasswordAuthentication no
---
> #PasswordAuthentication yes

Vom Client aus wird die Verbindung ein weiteres Mal getestet:

:~$ ssh -i .ssh/key_rsa tktest@192.168.56.101
Agent admitted failure to sign using the key.
Permission denied (publickey).

Im oben genannten Beispiel wurde der Dialog zum Eingeben des Schlüssel-Passworts abgebrochen. Da das Anmelden via Passwort deaktiviert wurde, war die Anmeldung am System nicht möglich.

Passwort-Authentifizierung nur für einen User verbieten

Eine weitere Möglichkeit, bei der Passwort-Authentifizierung nicht komplett deaktiviert wird, ist die Passwort-Anmeldung für spezielle User zu deaktivieren. Dadurch kann sich z.B. einem User, der am Server keine sudo-Rechte besitzt am Server anmelden. Um root-Rechte zu erlangen muss daraufhin zumindest ein weiteres Passwort eine Users mit sudo-Rechten herausgefunden werden. Außerdem gibt es die Möglichkeit, User komplett von ssh auszunehmen:

:~$ sudo diff /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
88,91d87
< 
< DenyUsers test
< Match User tktest
<     PasswordAuthentication no

Dieses Beispiel:

  • Verbietet den SSH-Zugang für den User test
  • Deaktiviert die Passwort-Authentifizierung für den User tktest
  • Für alle anderen User bleibt die Passwort-Authentifizierung erhalten.


Foto Georg Schönberger.jpg

Autor: Georg Schönberger

Georg Schönberger, Abteilung DevOps bei der XORTEX eBusiness GmbH, absolvierte an der FH OÖ am Campus Hagenberg sein Studium zum Bachelor Computer- und Mediensicherheit, Studium Master Sichere Informationssysteme. Seit 2015 ist Georg bei XORTEX beschäftigt und arbeitet sehr lösungsorientiert und hat keine Angst vor schwierigen Aufgaben. Zu seinen Hobbys zählt neben Linux auch Tennis, Klettern und Reisen.


Das könnte Sie auch interessieren

Linux Performance Auswertung mit collectd
Ubuntu
Ubuntu-Server-Installation mit Software-RAID