• Fakenamegenerator
• Tabbed Console für Windows
• How to Convert RHEL 5 to CentOS 5
• SSHFS und globaler Namespace
• System Administrator Interview Cheat Sheet

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

The US-CERT is reporting that there is active attacks against Linux environments using stolen SSH keys. There is a new rootkit out, Phalanx2 which is dropped by attackers which, among the usual rootkit tasks, steal any SSH key on a system. The attackers then, presumably, use those stolen keys (the ones without passwords/passphrases at least) to get into other machines.
SANS ISC

Glücklicherweise gibt es pam-ssh, welches die Sache wieder erträglich macht. Bei KDE muss das Benutzer-Passwort identisch mit der Passphrase sein, GDM ist so elegant und fragt danach. Anschließend merkt man von der Passphrase nichts mehr.

It is strongly recommended that all cryptographic key material which has
been generated by OpenSSL versions starting with 0.9.8c-1 on Debian
systems is recreated from scratch

alarmierend genug sein. Ubuntu ist da deutlicher:

This includes the automatically generated host keys used by OpenSSH, which are the basis for its server spoofing and man-in-the-middle protection.

Genau, eigentlich jeder mit einen Server auf dem eines der obigen Betriebs-Systemen läuft ist damit direkt von dieser Sicherheitslücke betroffen. Um, zum Beispiel auf einen Root-Server, bei Debian Etch neue Keys zu erzeugen sollte man zur Sicherheit eine zweite SSH-Session aufmachen, dann die alten Keys löschen und neue erzeugen:

 # apt-get update && apt-get -y upgrade
# cd /etc/ssh
# rm ssh_host_*
# /var/lib/dpkg/info/openssh-server.postinst configure

Danach ausloggen, den alten Key aus der ~/.ssh/know_hosts löschen und neu verbinden. Fertig.

via TCP-Blog