Sicheres SSH
28. Dezember 2008 | 
Autor: Die Secure Shell (SSH) ist heute das Maß der Dinge wenn es um einen sicheren Zugriff auf Server geht. Nichts ist allerdings so gut, das man es nicht noch ein bischen verbessern könnte. Besonders wenn man etwas mehr Kontrolle über die Dinge haben möchte, muss man ein wenig Hand anzulegen.
Kontrolle sichern
Zuallererst gilt es dem Benutzer die Kontrolle über das authorized_keys-File zu entziehen, denn die später beschriebenen Maßnahmen haben keinen Sinn, wenn der Benutzer sie einfach umgehen kann. Denn normalerweise liegt diese Datei im Home-Verzeichnis des Benutzer und er könnte sie einfach löschen und neu erstellen. Genau an dieser Stelle wird angesetzt, indem man auf den betroffenen Systeme die /etc/ssh/sshd_config ändert:
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
Durch diese Änderung liegen die Key-Files in /etc/ssh/authorized_keys/ und tragen den Namen des Benutzers. Durch entsprechende Dateiberechtigungen können Änderungen nur noch durch Root vorgenommen werden:
# ls -l insgesamt 16 -rw-r----- 1 root joern 397 25. Dez 23:13 joern -rw------- 1 root root 396 25. Dez 16:53 root
Zugriff absichern
Nun können Restriktionen für die SSH-Session im Key-File hinterlegt werden:
from="*.aumund.org",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa AAAAB3NzaC1yc2[..]EyqAw== joern@cm-master
Dieser Benutzer darf sich also nur von Hosts der aumund.org Domäne einloggen, es gibt kein Port- und X11-Forwarding und auch keine interactive Shell. Alle Optionen finden sich in der Man-Page (man sshd im Abschnitt AUTHORIZED_KEYS FILE FORMAT)
Sicheres Automatisieren
Mit SSH lassen sich wunderbar einfach Aufgaben automatisieren. Normalerweise nimmt man dazu einen Key ohne Passphrase. Wem das nicht reicht steht vor einem Problem: Der ssh-agent funktioniert nur solange man angemeldet ist. Hier hilft KeyChain aus, denn es setzt einen SSH-Agenten pro Benutzer und nicht einen pro Session.
Die Benutzung ist sehr einfach. Nach der Installation erweitert man die .bash_profile des betroffenen Benutzers:
/usr/bin/keychain ~/.ssh/id_rsa ~/.ssh/id_dsa
source ~/.keychain/${HOSTNAME}-sh > /dev/null
Beim nächsten Anmelden wird dann die Benutzer-Session aufgesetzt
KeyChain 2.6.8; http://www.gentoo.org/proj/en/keychain/ Copyright 2002-2004 Gentoo Foundation; Distributed under the GPL * Initializing /home/joern/.keychain/cm-master-sh file... * Initializing /home/joern/.keychain/cm-master-csh file... * Initializing /home/joern/.keychain/cm-master-fish file... * Starting ssh-agent * Warning: can't find /home/joern/.ssh/id_dsa; skipping * Adding 1 ssh key(s)... Enter passphrase for /home/joern/.ssh/id_rsa: Identity added: /home/joern/.ssh/id_rsa (/home/joern/.ssh/id_rsa)
und steht nun bis zum nächsten Reboot(!) zur Verfügung. An der Sache mit dem Reboot sollte man immer denken, wenn man Aufgaben automatisiert hat, ansonsten kann es zu ernsten Problemen kommen.
Referenzen:
Playing with OpenSSH public keys
Secure, Automated, Key based SSH
Schlagworte:
Solche Einstellungen gehören imho nicht in die authkeys sondern in die sshd-Config.
Aus der Example-Config:
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server
Dann muss man dem Benutzer auch nicht die Rechte auf die Datei entziehen. Weiterhin klappt das auch mit Gruppen usw.
Dem SSH-Agent kann man beim Start mit -a den selbst gewünschten Socket vorgeben und diesen dann später von Hand in die Umgebungsvariable SSH_AUTH_SOCK schreiben. Das funktioniert auch vorzüglich in Init-Scripts, damit ein Daemon anfangen kann, den Agent zu nutzen, sobald er initialisiert ist. Es sind also keine dubiosen Tools vom finsteren Grund der Gentoo-Bastelkiste erforderlich. :-)
@Jens: Ja, kenne ich. Stelle ich mir aber schwer zu parsen vor.
@Martin: Das klingt auch nach einer guten Idee :)