Sicherheit von SSH (etwas) erhöhen
Freitag, den 16. Mai 2008
Nachdem kürzlich bekannt wurde, daß sich beim Patchen der OpenSSL-Bibliothek in Debian 4.0 ein Bug eingeschlichen hat, welcher alle unter Debian mit OpenSSL erzeugten Schlüssel (egal ob SSH, SSL oder OpenVPN) quasi unbrauchbar macht, haben wir nun in mehrstündiger Arbeit alle Schlüssel ausgetauscht. Ich warte gerade noch auf die letzten aktualisierten SSL-Zertifikate (ja, auch die müssen neu ausgestellt werden, da sich ja der Private Key geändert hat).
An dieser Stelle ein paar Hinweise zur zusätzlichen Absicherung von SSH-Zugängen:
- am besten SSH durch entsprechende Firewall-Regeln nur von bestimmten IPs aus erlauben (z.B. vom Büro-Netzwerk)
- den privaten SSH-Schlüssel nur auf einem “Kommunikations-Server” ablegen, und von dort aus auf den jeweiligen Zielserver connecten. Also nicht den privaten Schlüssel auf jeder Maschine ablegen, nur um
faul bequem von jedem Rechner auf jeden Rechner connecten zu können.
- NIEMALS root-Anmeldung per SSH erlauben! In /etc/ssh/sshd_config den Eintrag “PermitRootLogin” auf “no” setzen.
- Falls z.B. für automatische Backups ein root-Login möglich sein muss, dann PermitRootLogin auf “forced-commands-only” setzen, und den jeweils erlaubten Befehl in der authorized_keys2 dem jeweiligen Schlüssel voranstellen, z.B.: command=”/usr/bin/rsync –server –sender […]” ssh-rsa […]
- Falls man den Zugriff auf SSH nicht per Firewall regulieren kann/will, kann man in authorized_keys2 mit der Option from festlegen, von wo aus dieses Login akzeptiert wird, z.B.: from=”12.34.56.78″ ssh-rsa […]
Weitere Ideen?
Nachdem kürzlich bekannt wurde, daß sich beim Patchen der OpenSSL-Bibliothek in Debian 4.0 ein Bug eingeschlichen hat, welcher alle unter Debian mit OpenSSL erzeugten Schlüssel (egal ob SSH, SSL oder OpenVPN) quasi unbrauchbar macht, haben wir nun in mehrstündiger Arbeit alle Schlüssel ausgetauscht. Ich warte gerade noch auf die letzten aktualisierten SSL-Zertifikate (ja, auch die müssen neu ausgestellt werden, da sich ja der Private Key geändert hat).
An dieser Stelle ein paar Hinweise zur zusätzlichen Absicherung von SSH-Zugängen:
- am besten SSH durch entsprechende Firewall-Regeln nur von bestimmten IPs aus erlauben (z.B. vom Büro-Netzwerk)
- den privaten SSH-Schlüssel nur auf einem “Kommunikations-Server” ablegen, und von dort aus auf den jeweiligen Zielserver connecten. Also nicht den privaten Schlüssel auf jeder Maschine ablegen, nur um
faulbequem von jedem Rechner auf jeden Rechner connecten zu können. - NIEMALS root-Anmeldung per SSH erlauben! In /etc/ssh/sshd_config den Eintrag “PermitRootLogin” auf “no” setzen.
- Falls z.B. für automatische Backups ein root-Login möglich sein muss, dann PermitRootLogin auf “forced-commands-only” setzen, und den jeweils erlaubten Befehl in der authorized_keys2 dem jeweiligen Schlüssel voranstellen, z.B.: command=”/usr/bin/rsync –server –sender […]” ssh-rsa […]
- Falls man den Zugriff auf SSH nicht per Firewall regulieren kann/will, kann man in authorized_keys2 mit der Option from festlegen, von wo aus dieses Login akzeptiert wird, z.B.: from=”12.34.56.78″ ssh-rsa […]
Weitere Ideen?



