SSH-Anmeldung an der CCU ohne Passwort mit Public Key (hier CCU3)

[maddes]

Hallo zusammen,

aus Sicherheitsgründen sowie für Skripte möchte man sich vielleicht auch passwortlos an der CCU (hier CCU3) anmelden.
Im Forum gibt es viele Posts mit unterschiedlichsten Lösungen, um die üblichen Probleme zu umgehen, welche aus meiner Sicht leider nie 100% sauber gelöst waren.
Letztendlich hat sich herausgestellt, dass die CCU Firmware (hier Version 3.65.11, 2022-10) eine unglückliche Verzeichnisstruktur verwendet.

Update 2023-07: Das Changelog von 3.69.6 listet einen Workaround für das hier dargestellte Problem auf.

Voraussetzungen:

• SSH-Zugang ist bereits über die Web-UI unter "Settings > Control Panel > Security" aktiviert und ein Passwort gesetzt (Benutzer ist "root")
• Anmeldung an der CCU via SSH mit Passwort ist erfolgreich
• Ein Public/Private Key ist vorhanden, sowie Kenntnisse zu deren Erstellung (ssh-keygen, PuttyGen, etc.) und Nutzung mit SSH
• Kenntnisse mit einer Linux/BSD/MacOS-Shell; auf der CCU ist dies Busybox, eine Shell mit reduzierter Funktionalität und Befehlen
• Kenntnisse zum Auslesen von Fehlermeldungen mit "less /var/log/messages"

Ziel dieses Posts:
Anmeldung an der CCU via SSH mit Public/Private Key

Erfolgreich geteste Key-Typen:

• RSA mit 2048 Bits
• EdDSA25519

Typisches Problem:
Aufgrund der empfohlenen Standard-SSH-Server-Einstellung "StrictModes yes" wird die Datei "authorized_keys" im Verzeichnis "/usr/local/etc/ssh" nicht berücksichtigt, da die Berechtigungen des übergeordneten Verzeichnis zu freizügig sind.
Dieser Fehler wird entsprechend in "/var/log/messages" bei jedem Zugriff protokolliert.

Das Verzeichnis "/usr/local/etc/ssh" enthält den Inhalt für das Benutzerverzeichnis ".ssh" des Benutzers "root" ("/root/.ssh"), welches striktere Berechtigungen verwenden sollte.
Das übergeordnete Verzeichnis "/usr/local/etc" enthält aber noch weitere System-Konfigurationen, welche standardmäßig von allen Anderen (others; öfter auch Welt/world genannt) gelesen können sollte.
Es sind also 2 verschiendene Dinge in "/usr/local/etc" von der Firmware dort platziert worden: die System-Konfiguration und die benutzer-eigene SSH-Konfiguration von root. Nach dem Linux Standard sollen "etc"-Verzeichnisse nur System-Konfigurationen enthalten.
Entsprechend sieht OpenSSH das Verzeichnis "/etc/ssh" für die SSH.System-Konfiguration vor. Für benutzer-eigene SSH-Konfiguration wird von OpenSSH das Verzeichnis ".ssh" im Home-Verzeichnis des Benutzers vorgesehen.
Aufgrund des CCU-Embedded-System mit partitioniertem Flash-Speicher muss hier etwas getrickst werden, aber dies ginge besser als in der aktuellen Firmware (2023-11).

CCU Lösung:
Firmware 3.69.6 hat dies "gefixt" (Changelog). Wobei nur die Berechtigungen für das Verzeichnis "/usr/local/etc/ssh/" korrigiert wurden. Das Filesystem wurde nicht an den Linux-Standard angepasst.
Wer diesen "Fix" vorab erledigen bzw. sicherstellen möchte:

Code: Alles auswählen

## fix permissions
chmod -v u=rwx-s,go=-s /usr/local/etc/ssh

Beim Erstellen eines Backup enthält die *.sbk-Datei (tar-Archiv) das Verzeichnis "/usr/local/etc/ssh" mit seinen Berechtigungen.
Beim Zurücksetzen der CCU wird anscheinend "/usr/local/" komplett initialisiert (diesmal korrekt alles mit User- und Gruppen-ID "root"; siehe Post Post Scriptum ganz unten). Die Berechtigungen passen zu einem "etc"-Verzeichnis aber nicht zu "StrictModes yes". Also wieder alles beim Alten.
Beim Einspielen eines Backup werden das Verzeichnis "/usr/local/etc/ssh" wieder so erstellt wie beim Zustand des Backups.
Diese Lösung überlebt auch ein Firmware-Update.

P.S.:
Wer meine frühere Lösung mit dem verschobenen "ssh" Verzeichnis rückgängig machen möchte, der entfernt einfach den symbolischen Link "/usr/local/etc/ssh", und verschiebt dann das "ssh" Verzeichnis aus "/usr/local/" wieder runter nach "/usr/local/etc/".

"Korrektere" Lösung:
Das Filesystem an den Linux Standard annähern. Aufgrund des Embedded-System mit partioniertem Flash-Speicher geht das nicht zu 100%.
Das Verzeichnis "/usr/local/etc/ssh" enthält nur die System-SSH-Konfiguration.
Die Benutzer-SSH-Konfiguration von root kommt in ein separates Verzeichnis unterhalb von "/usr/local/" (also nicht innerhalb "etc").
Gleichzeitig könnte man individuelle Konfigurations-Möglichkeiten für SSH eröffnen.

Aufbau des Filesystem in der RW-Partition unterhalb "/usr/local/":

Code: Alles auswählen

/usr/local/etc/ssh/     drwxr-xr-x
 \-> ssh_host_*_key*
     ssh_config.d/      drwxr-xr-x (Erweiterung für individuelle Konfigurationen, debian-like)
     sshd_config.d/     drwxr-xr-x (Erweiterung für individuelle Konfigurationen, debian-like)

/usr/local/.ssh/        drwx------
 \-> authorized_keys    -rw-------

Diese Verzeichnise und Dateien werden im Read-Only Filesystem über symbolische Links eingebunden:

Code: Alles auswählen

/etc/ssh/
 \-> ssh_host_*_key* --> /usr/local/etc/ssh/ssh_host_*_key*
     ssh_config.d/   --> /usr/local/etc/ssh/ssh_config.d/
     sshd_config.d/  --> /usr/local/etc/ssh/ssh_config.d/

/root/
 \-> .ssh/ --> /usr/local/.ssh/

Dann noch die Dateien "ssh_config" und "sshd_config" am Ende um jeweils eine Zeile erweitern, um individuelle SSH-Konfigurationen zu erlauben:

Code: Alles auswählen

/etc/ssh/ssh_config:
Include /etc/config/ssh/ssh_config.d/*.conf

/etc/ssh/sshd_config:
Include /etc/config/ssh/sshd_config.d/*.conf

Unsaubere Lösungen:

• SSH-Server-Einstellung "StrictModes" auf "no" stellen
  Auch wenn die CCU ein Embedded-Gerät ist, welches normalerweise nicht als Multi-User-Umgebung genutzt, und die CCU normalerweise nur aus dem LAN erreicht werden kann, sollte man trotzdem seine Dateien korrekt schützen.
  Außerdem muss man eine Modifikation an der "Firmware" (korrekter: dem read-only Filesystem) vornehmen, welche nach einem Firmware-Update wieder verschwunden ist.
• Berechtigungen von "/usr/local/etc" restriktiver setzen
  Dies widerspricht der klassischen Berechtigung für "etc"-Verzeichnisse.
  Außerdem könnten andere System-Komponenten damit jetzt oder in Zukunft Probleme bekommen.
  Bei Interesse zur Definition der Linux File System Hierarchie siehe https://wiki.linuxfoundation.org/lsb/fhs

P.P.S.:
Die Firmware hat noch ein weiteres Problem im schreibbaren Filesystem: falsche und nicht existierende User- und Gruppen-IDs.
Ich konnte mehrere Dateien und Verzeichnisse mit User-ID 108 und Group-ID 110 finden.
Diese Benutzer existieren aber nicht in der CCU3-Firmware 3.65.11 (2022-10).
Anscheind sind dies Überreste älterer Firmwares oder des Images bei der Herstellung.
Deswegen sollte man bei der Erstinstallation nach dem Firmware-Update die CCU auf Werkseinstellung zurücksetzen, damit diese Überreste verschwinden, und man diese nicht per Backups ewig mitnimmt.

Selber aufspüren solcher Dateien:

Code: Alles auswählen

find -P / \( -user 108 -o -user 110 -o -group 108 -o -group 110 \) -print0 | xargs -0 -- ls -lad

find -P / -type d \( -name 'dev' -o  -name 'proc' \) -prune -o \( ! -user root -o ! -group root \) -print0 | xargs -0 -- ls -lad

Gefunden in CCU3-Firmware 3.65.11 (2022-10):

Code: Alles auswählen

/usr/local/.doResizeLocalFS
/usr/local/etc/
/usr/local/etc/config/
/usr/local/etc/config/shadow

[maddes]

Update Firmware 3.71.12

• Works out-of-the-box with a cleanly reset CCU
• root's .ssh folder still linked to "/usr/local/etc/ssh/" but link target has more restrictive settings:

  Code: Alles auswählen

  /usr/local/etc/
   drwx------    2 root     root          4096 Nov 29 14:50 ssh
  

Could be possible that this would have been sufficient for previous firmware too, but is still an abuse of an "etc" folder.

Code: Alles auswählen

## fix permissions
chmod -v u=rwx-s,go=-s /usr/local/etc/ssh