OpenWRT: OpenSSH statt Dropbear

Da der bei OpenWRT vorinstallierte SSH-Daemon Dropbear im Funktionsumfang eingeschränkt ist, kann es sich zur Absicherung der SSH-Verbindung lohnen ihn durch OpenSSH zu ersetzen. Zunächst wird der Dropbear auf einen anderen Port gelegt (hier auf Port 2222).

uci set dropbear.@dropbear[0].Port=2222
uci commit dropbear
/etc/init.d/dropbear restart

Danach unbedingt ausprobieren, ob der dropbear auf dem neuen Port erreichbar ist, falls bei der Installation von OpenSSH etwas schieft läuft, muss ggf. auf Dropbear zurückgegriffen werden.

$ ssh -p 2222 root@192.168.1.1

Wichtig: Bei OpenSSH ist in der Default-Konfiguration eine Anmeldung mit leerem Passwort nicht möglich. Daher unbedingt sicherstellen, dass für den root-User ein Passwort vergeben wurde. Danach wird OpenSSH (inkl. SFTP-Unterstützung) installiert, aktiviert und gestartet:

opkg update
opkg install openssh-server openssh-client openssh-moduli openssh-sftp-server
/etc/init.d/sshd enable
/etc/init.d/sshd start

Jetzt sollte eine SSH-Verbindung auf Port 22 möglich sei: Anmerkung: Ggf. hat sich der SSH-Client die SSH-ID des Hosts gemerkt. In diesem Fall kann es sein, dass der Client die Verbindung mit folgender MEldung abbricht:

[...]
RSA host key for 192.168.1.1 has changed and you have requested strict checking.
Host key verification failed.

In diesem Fall muss der Eintrag für den OpenWRT-Router aus der Datei ~/.ssh/known_hosts entfernt werden. Danach sollte die Verbindung zum OpenWRT wieder problemlos aufgebaut werden können. War die Verbindung zum OpenSSH-Server erfolgreich, kann der Dropbear deaktiviert und deinstalliert werden

/etc/init.d/dropbear disable
/etc/init.d/dropbear stop
opkg remove dropbear

Damit ist der Grundstein für einen sicheren SSH-Zugang gelegt. Jetzt muss nur noch die OpenSSH-Konfiguration angepasst werden.Im ersten Schritt werden neue SSH-Schlüssel erzeugt:

cd /etc/ssh
rm ssh_host_*key*
ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N ''
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N ''

In der Datei /etc/ssh/moduli werden alle Modil < 2000 Bits gelöscht:

awk '$5 > 2000' /etc/ssh/moduli > "${HOME}/moduli"
if [ -s "${HOME}/moduli" ]; then mv "${HOME}/moduli" /etc/ssh/moduli; fi;

Anschließend wird ein SSH-Key auf dem Client erzeugt und auf den Router übertragen. Daher sind folgende Kommandos auf dem Client auszuführen, mit der sich zum Router verbinden soll:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100
ssh-copy-id -i ~/.ssh/id_ed25519.pub <username>@192.168.x.y

Danach habe ich noch folgende Parameter in der Datei /etc/ssh/sshd_config angepasst oder ergänzt (vorher sollte ein Backup der Datei angelegt werden):

# Der SSH-Daemon soll nur auf dem LAN-Interface verfügbar sein
 ListenAddress 192.168.1.1

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key

StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
IgnoreUserKnownHosts yes
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

UsePrivilegeSeparation sandbox 

# override default of no subsystems
Subsystem       sftp    /usr/lib/sftp-server

# Wichtig: Es ist zu prüfen, das die Gruppe ssh-user existiert 
# und der Benutzer der Gruppe zugeordnet wurde.
# Ansonsten ist ggf. kein Login mehr möglich
AllowGroups ssh-user

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-5

Wenn alles richtig eingetragen wurde, sollte der SSH-Server nach einem /etc/init.d/sshd reload wieder auf Port 22 des internen Interfaces Verfügbar sein. Startet der Server nicht korrekt, dann sind die Konfiguration auf fehlerhafte Einträge zu überprüfen. Anschließend wird ein SSH-Key auf dem Client erzeugt und auf den Router übertragen. Die folgende Kommandos werden daher auf dem Client ausgeführt, mit der sich zum Router verbinden soll:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100
ssh-copy-id -i ~/.ssh/id_ed25519.pub <username>@192.168.1.1

Wird danach vom Client die Verbindung mit einem unpriviligierten User und mit SSH-Schlüssel aufgebaut werden, dann sollten abschließend noch folgende Punkte in der Konfiguration angepasst werden:

# ACHTUNG: Nur deaktivieren, wenn vorher ein unpriviligierter Benutzer angelegt wurde
PermitRootLogin  no

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

# Change to no to disable s/key passwords
ChallengeResponseAuthentication no

Nach einem Neustart des SSH-Daemons ist die Einrichtung abgeschlossen.