Debian – SSH Tunnel mittels Zertifikat und ohne Passwort authentifizieren

Systeme sind zwei Debian Wheezy
Ziel ist es zwischen dem Client und Server einen SSH Tunnel aufzubauen. In diesem Fall läuft auf dem Client das Monitoring Tool Cacti. Es soll ein Script / Befehl auf dem Server ausführen.

Vorwort
Server- ist der Server der die Verbindung annimmt und das Script ausführt und benötigt mindestens das Paket openssh-server
Client – ist der die SSH Verbindung aufbauen soll, er benötigt mindestens das Paket openssh-client

Zugriff mit Passwort vom Client auf Server
Wenn bereits das Paket „openssh-server“ auf beiden Clients installiert ist, kann man eine Abfrage Remote auch kurz so durchführen:

# ssh root@<hostname-client> -p22 ‚/home/<script>‘
root@<hostname-client>’s password:

sh root@<hostname-client> -p22 ‚df -h‘
root@<hostname-client>’s password:

Wie man hier jedoch schön sehen kann wird jedes Mal das Passwort das Users (hier root) verlangt. Möchte man dies nun automatisieren, dann wäre das nur hinderlich und daher folgt nun die Einrichtung mittels Zertifikat.

1. Zertifikat mittels ssh-keygen erstellen – AM CLIENT:

# cd ~ oder cd /root/
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory ‚/root/.ssh‘.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
bb:49:60:14:11:6c:18:ba:c9:36:af:4b:6b:4f:6b:f2 root@<client>
The key’s randomart image is:
+–[ RSA 2048]—-+
|    .++o         |
|   .. o.         |
|  .  ..          |
| . o .           |
|  *   o S        |
| . o . . .       |
|  . o   o        |
| .o+.. . o       |
| .+*E   o        |
+—————–+

Erklärung
In diesem Fall habe ich das als root im Home von root ausgeführt. Wichtig ist ein Passwort für das Zertifikat zu vergeben. Dieses verschlüsselt den Schlüssel mit einem AES-CBC Algorythmus, sodass jemand der den privaten Schlüssel in die Finger bekommt, ihn nicht ohne Passwort, quasi im Klartext, lesen kann.

Der Fingerprint: bb:49:60:14:11:6c:18:ba:c9:36:af:4b:6b:4f:6b:f2 ist eine 16-stellige Hexadezimalzahl, die z.B. auf einer Webseite veröffentlicht werden kann und der Verifizierung / Prüfung, des Schlüssels auf Korrektheit, dient.

Darunter folgt eine ASCII-Grafik mit deren Hilfe der Fingerprint optisch dargestellt wird.

-b = Anzahl der Bits für einen Key/Schlüssel, min sind 768, Standard sind 2048, DSA benötigt genau 1024 und ECDS kann 256, 384 und 521 bit
-t = Type der Verschlüsselung – rsa1 (Protokoll1), dsa, ecdsa oder rsa (Protokoll2)

die Dateien
Nach erfolgreicher Erstellung sind folgende Dateien im .ssh Verzeichnis zu finden:
# cd .ssh/
id_rsa
id_rsa.pub

Die Namen deuten es bereits an, die id_rsa ist das private und die id_rsa.pub das öffentliche Zertifikat. Der Inhalt des privaten Schlüssel bestätigt obige Aussage zur Verschlüsselung dieser:
# cat id_rsa
—–BEGIN RSA PRIVATE KEY—–
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,ADD8434AC307FF3E0FED9C84B383E772
[….]

Übergabe des öffentlichen Schlüssel vom Client auf den Server
Als nächstes muss der öffentliche Schlüssel noch auf den Server übertragen werden. Ich erinnere kurz, der Client soll später die Abfragen via SSH am Server durchführen. Da bereits OpenSSH auf beiden Geräten installiert ist, kann die Übertragung darüber, noch mit einem Passwort, erfolgen. Als Tool verwende ich ssh-copy-id, ebenso gut ist auch secure-copy (scp) oder ähnliches verwendet. Mit der Option -i wird die Identitätsdatei (identity file) ~/.ssh/id_rsa.pub, egal was dort beim ssh-agent eingestellt ist, verwendet. Ansonsten ssh-add -L verwenden

# ssh-copy-id -i id_rsa.pub root@<hostname-server>
The authenticity of host ‚<hostname-server> (<hostname-server>)‘ can’t be established.
ECDSA key fingerprint is 1e:05:c7:d9:80:f9:8f:9a:3a:4b:36:aa:59:9e:29:ac.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‚<hostname-server>‘ (ECDSA) to the list of known hosts.
root@<hostname-server>’s password:
Now try logging into the machine, with „ssh ‚root@<hostname-server>'“, and check in:

~/.ssh/authorized_keys

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

Hier ist auch schön zu sehen, dass die ssh Verbindung zum ersten Mal aufgebaut wurde und der <hostname-server> noch nicht in der know_hosts Liste enthalten und vertraut wird. Daher hier mit <yes> bestätigen.

Kontrolle Dateiberechtigung auf dem Server

Da die Dateien jeweils in das Homeverzeichnis kopiert bzw. erstellt wurden, sollte auch nur der entsprechende Benutzer Rechte zum lesen und schreiben haben, sonst kein anderer, auch nicht die Gruppe. Nachträglich lässt sich das folglich ändern:

# chmod 600 ~/.ssh/authorized_keys

Kontrolle vom Client aus

# ssh -i ~/.ssh/id_rsa root@<hostname-server>
Enter passphrase for key ‚id_rsa‘:

Als Passwort muss nicht etwa das vom Root des <hostname-server> eingegeben werden, sondern das was wir oben bei der Erstellung vergeben haben.

Kontrolle vom Server aus

# ls ~/.ssh/
authorized_keys  known_hosts

Einrichtung unter dem User des Webservers

Da Cacti bei mir nicht unter root läuft und die Scripte und der Poller gemäß „/etc/cron.d/cacti“ -> als www-data, also Webserver, aufgerufen werden. Müssen die Keys noch kopiert werden:

# mkdir -p /var/www/.ssh/
# cp /root/.ssh/id_rsa* /var/www/.ssh/
# cp /root/.ssh/authorized_keys /var/www/.ssh/
 Nun noch die Berechtigungen anpassen: # chown -R www-data:www-data/var/www/.ssh
# chmod 0700 /var/www/.ssh
# chmod 0600 /var/www/.ssh/id_rsa

Verbindung ohne Passwort Abfrage

Hierfür kann z.B. der ssh-agent genutzt werden, er kommt mit jeder Installation des openssh-server und openssh-cilent mit:

# ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-Y4GMcXBGJQZt/agent.20276; export SSH_AUTH_SOCK;
SSH_AGENT_PID=20277; export SSH_AGENT_PID;
echo Agent pid 20277;

Wir dieser ausgeführt gibt er die entsprechenden genutzten Variablen aus. Mit  eval folgendes „Agent pid 20386“

Dies nutzen wir und tragen den SSH-Agent in die /etc/profile ein, somit startet er automatisch bei jeder Session:

echo ‚eval `ssh-agent`‘ >> /etc/profile

Nun müssen wir im noch mitteilen welchen Schlüssel er benutzen soll. Das Passwort ist entsprechend das oben verwendete:

# ssh-add ~/.ssh/id_rsa
Enter passphrase for /root/.ssh/id_rsa:
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)

ACHTUNG ! Der SSH-Agent läuft weiter, auch nach Logout des Users, daher bleiben die Instanzen / Session Zombies am Leben und sammeln sich. Mit ps sind diese als „defunct“ zu erkennen. Daher ggf. Keychain oder GnuPG-Agent nutzen.

# ps aux |grep ssh
root      2401  0.0  0.1  49848  1208 ?        Ss   Sep10   0:00 /usr/sbin/sshd
root     19901  0.0  0.3  71208  3584 ?        Ss   14:13   0:00 sshd: root@pts/0
root     20277  0.0  0.0  12384   332 ?        Ss   14:29   0:00 ssh-agent
root     20384  0.0  0.0  12384   336 ?        Ss   14:33   0:00 ssh-agent
root     20386  0.0  0.0  12384   768 ?        Ss   14:33   0:00 ssh-agent
root     20559  0.0  0.0   9896   888 pts/0    S+   14:41   0:00 grep ssh

Test SSH-Verbindung mittels Zertifikat und ohne Passwort:

# su www-data
# ssh <hostname-server> -p22
Linux <hostname-server> 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1+deb7u1 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Sep 19 14:10:37 2013 from <hostname-client>
root@<hostname-server>:~#

PERFEKT !

Verbesserungen
– Chrooted laufen lassen
– mit extra Benutzer
– root verbieten
– Schlüssellänge von 4096 bit verwenden
– statt SSH-Agent -> Keychain oder GnuPG-Agent nutzen

Links http://www.math.ucla.edu/~andergroup/public/tools/SSH_Howto/Using_ssh_agent.html