ssh mit public key

ich habe dazu schon mehrfach was geschrieben - aber man lernt ja immer wieder dazu. Deshalb noch ein ziemlich komprimierter Artikel: 

Ein HowTo für die Automatisierung von Remote Aufgaben in FHEM über ssh. 

Nachtrag 2023: Es gibt einen neuen Artikel, der die Einrichtung ganz kompakt mit einem Script zeigt.

Ich habe den Artikel primär so geschrieben, dass der ssh Zugang für einen anderen als den aktuellen user eingerichtet wird. Für den aktuell angemeldeten Benutzer ist die Beschreibung aber fast gleich, nur einfacher. Zunächst die Voraussetzungen in der FHEM Kommandozeile testen/schaffen. (Im Terminal einfach {qx()} weglassen).

FHEM läuft unter dem Benutzer fhem?

{qx(whoami)}

Dieser Benutzer hat schon einen Public Key?

{qx(ls -lha .ssh/id_*.pub || Echo 'Datei nicht gefunden')}

Falls noch kein ssh Key existiert (oder ein Neuer gebraucht wird) wird so ein Key ohne Passphrase erzeugt (Achtung: ein existierendes Key Pärchen wird überschrieben):

{qx(ssh-keygen -f ~/.ssh/id_rsa -P "" -t rsa)}

Alternativ kann mit dem neueren ed25519 Verfahren gearbeitet werden, dies ist schneller und kompakter.

{qx(ssh-keygen -f ~/.ssh/id_ed25519 -P "" -t ed25519)}

Man kann den Public Key (1 Textzeile, 3 Worte) auch einfach ausgeben lassen und über das Browserfenster und einen Editor manuell auf das Zielsystem in die Datei .ssh/authorized_keys kopieren:

{qx(cat ~/.ssh/id_xxx.pub)}

Einrichtung

Der folgende Code wird im Terminalfenster auf einem (lokalen) Linux System ausgeführt (dort wo FHEM läuft)  und zeigt die Einrichtung für verschiedene Zielsysteme (remote). Während der Einrichtung wird das Passwort des Benutzers auf dem Zielsystem u.U. mehrfach abgefragt.

Bitte nur den zutreffenden Code ausführen! Je nach Key Typ den richtigen Dateinamen einsetzen!

Tipp: Die Codebox ist direkt editierbar: man kann überschreiben und direkt kopieren, es ist kein extra Editor notwendig.

#### alle Ziele
sudo -su fhem               # entfällt für den aktuellen Benutzer
ziel=user@host              # Benutzer und Host einmal eintragen
## 1 - Nur fuer alle Zielsysteme die ssh-copy-id nicht unterstützen
pkey=$(cat ~/.ssh/id_xxx.pub)
## 2 - Ziel Windows - danach Schritt 5
apath='.ssh'
ssh $ziel "findstr /c:\"$pkey\" $apath\authorized_keys ||mkdir $apath ||echo $pkey >>$apath\authorized_keys"
## 3 - Ziel openwrt - danach Schritt 5
apath='/etc/dropbear'
ssh $ziel "if ! grep -qs \"$pkey\" $apath/authorized_keys; then mkdir -p $apath; echo $pkey >>$apath/authorized_keys;fi"
### 4 - Ziel: Nur Linux Systeme mit ssh-copy-id
ssh-copy-id -i ~/.ssh/id_xxx $ziel
#### 5 - Fuer alle Ziele - Erfolgstest 
ssh $ziel                   # Test für den passwortfreien Zugang - Remote session!
exit                        # aus der ssh Test session vom Remotehost!
exit                        # aus der Anmeldung vom user fhem!  

Ein ganz schneller Funktionstest für die FHEM Kommandozeile.

{qx(ssh user\@host echo VomAnderenHost)}

Hinweis: Innerhalb von Perl muss das @ schützen!

Was passiert im Detail?

Wichtig ist, dass der RSA Key ohne Passphrase erzeugt wurde! Sonst wird bei der Verwendung des Schlüssel wieder ein Passwort abgefragt und die Ausführung von Befehlen per ssh funktioniert nicht automatisch! Die Einrichtung geschieht für den einzelnen Benutzer, nicht für das gesamte System!

Bei der Einrichtung wird

• der remote Host Schlüssel als vertraut in die lokale Schlüsseldatei (known_hosts) hinterlegt, und
• der Schlüssel des lokalen Benutzers in der Schlüsseldatei (authorized_keys) des remote Benutzers als vertraut hinterlegt. 

Durch Verwendung der Schlüssel kann nun die Autorisierung ohne weitere interaktive Abfrage erfolgen. Der lokale Benutzer kann sich als remote Benutzer am remote System anmelden.

Verwendung von sudo im Script

Schon zum shutdown des systems braucht man erhöhte Rechte. Diese werden z.B. über sudo erreicht, aber auch da muss man wieder verhindern, dass nach dem Passwort gefragt wird! Die Systeme sind da unterschiedlich voreingestellt. Bei manchen wird immer mal nach dem Passwort gefragt, bei manchen nie. Verantwortlich ist der Inhalt der (zutreffenden) Datei - /etc/sudoers bzw. /etc/sudoers.d/010_pi-nopasswd. 

Beispiele (debian, Raspberry OS)

# User privilege specification
root    ALL=(ALL:ALL) ALL

# Allow members of group sudo to execute any command
%sudo   ALL=(ALL:ALL) ALL

Ist der User Mitglied in der Gruppe sudo, dann wird er bei der ersten Verwendung nochmal nach dem Passwort gefragt, auch wenn er sich gerade neu angemeldet hat.   

pi ALL=(ALL) NOPASSWD: ALL

Der Benutzer pi muss niemals sein Passwort extra bei der Verwendung von sudo eingeben.

Empfehlung

Extra Benutzer anlegen und über eine Datei nach dem Vorbild /etc/sudoers.d/010_pi-nopasswd die Abfrage des Passwortes verhindern. Diese Dateien immer mit dem Editor visudo bearbeiten! 

Sicherheit

Die Anmeldung an einem System mit ssh und einem rsa Schlüssel ist so sicher wie der Account der den Schlüssel lesen und verwenden kann. Der Schlüssel ist so abgelegt, das er exklusiv nur von dem jeweiligen Benutzer gelesen/verwendet werden kann.

Durch die hier beschriebene Einrichtung, hat der Benutzer Zugriff auf ein zweites System. Hat der Benutzer im zweiten System sudo Rechte, hat fhem sudo Rechte an diesem System.

Wird fhem kompromittiert wird damit ein zweiter Benutzer  und ein zweites System kompromittiert.