Archiv

Artikel Tagged ‘SSH’

Links for 2009-05-28

28. Mai 2009 Kommentare ausgeschaltet

Links for 2009-01-01

1. Januar 2009 Kommentare ausgeschaltet
  • apt-dater provides a ncurses frontend to manage package updats on a large number of remote hosts using SSH.[..] supports [..] now also rug (openSUSE, …) and yum (e.g. CentOS, …) based systems
  • SSHauth is a plugin for pGINA that lets you authenticate your Windows users against one or more SSH server.
  • SSH Access Manager is a comprehensive access security management platform that permits IT professionals to easily establish and maintain an enterprise-wide SSH access security solution from a central location
  • rpmorphan finds „orphaned“ packages on your system (packages which have no other packages depending on their installation). A console and graphical interface is provided. It is clone of deborphan debian software. It provides also some others rpm tools.
  • Using the SSH agent from daemon processes – Martin hat eine einfache und elegante Lösung für den sicheren Umgang mit dem ssh-agent dokumentiert.

Sicheres SSH

28. Dezember 2008 3 Kommentare

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

Tags: , ,

Links for 2008-11-04

4. November 2008 1 Kommentar
Tags: , ,

SSH Keys ohne Passphrase sind böse!

27. August 2008 5 Kommentare

Ich konnte mich Anfangs nicht mit einer Passphrase für SSH anfreunden, ohne kann es aber fürchterlich nach hinten losgehen:

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.

Debian OpenSSL Schwachstelle – Nicht die SSH-Keys vergessen

13. Mai 2008 4 Kommentare

Die OpenSSL-Schwachstelle in Debian Etch, Ubuntu von Feisty bis Gutsy und alle anderen Derivaten kann man getrost als GAU bezeichnen, denn die Konsequenzen können dramatisch sein. Leute die öfters mit Verschlüsselung zu tun haben wird der Satz

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.

Poderosa – Windows SSH-Client mit Tabs

14. Dezember 2007 7 Kommentare

Wird nach Jahren wohl mal wieder Zeit für eine Wachablösung. Erst Teraterm, dann mit ttssh, Putty und nun Poderosa. Hauptgrund sind die fehlenden Tabs, welche unter Putty dazu führen eine Zoo von Fenstern auf dem Desktop zu haben.

Poderosa - Windows SSH-Client mit Tabs in Aktion

via TCP-Blog

Links for 2007-06-07

7. Juni 2007 Kommentare ausgeschaltet