Reverse ssh tunnel mit autossh

Eigentlich ist das Port-Forwarding im Router so eingestellt, dass der Remote Zugriff auf den Heimserver problemlos funktioniert. Leider hat der Provider aber die Möglichkeit den Router neu zu initialisieren (und damit meine Forward-Regeln zu löschen) und er macht auch massiv Gebrauch davon. Zwar kann der Server dann weiterhin mit dem Internet kommunizieren (und so auch als nagios-Server andere Server überwachen), der Zugriff von außen funktioniert aber nicht mehr.

Mit einem Server im Internet lässt sich dem Problem ein Schnippchen schlagen, in dem man den Heimserver anweist einen reverse ssh tunnel aufzubauen. Über diesen kann man später auf das Heimnetz zugreifen und die Port-Forwarding Regeln neu einspielen. Damit der Tunnel nach der Unterbrechung durch den Provider wieder hergestellt wird hilft autossh. Mit folgendem Eintrag in /etc/rc.local (Ubuntu Server):

sudo -u meinuser /usr/bin/autossh \
  -R 17777:localhost:22 -N meinserver.tld &

bleibt die Verbindung immer offen. Hier noch kurz die Erklärung der Einzelheiten:

  • sudo -u meinuser: Die Datei /etc/rc.local wird als root ausgeführt, der SSH-Tunnel soll aber unter meinem User aufgebaut werden
  • autossh -R 17777:localhost:22: autossh übergibt alle Parameter an ssh. Hier wird der reverse Tunnel auf Port 17777 zum Port 22 der lokalen Maschine hergestellt.
  • -N: ssh soll keine Shell starten, nur den Tunnel bereit stellen

Natürlich müssen die ssh-Schlüssel für den eigenen Account mit dem Server meinserver.tld zuerst ausgetausch werden, damit ein login ohne Passwort möglich ist. Anschließend kann man mit den Kommandos

ssh meinuser@meinserver.tld
ssh -p 17777 localhost

vom Internet aus auf den Heimserver zugreifen. Der Port 17777 ist dabei nur für Benutzer am Server meinserver.tld zugängig.

vsftp mit chroot für sehr eingeschränktes FTP

Für verschiedene Dienste bekommen wir stündlich, beziehungsweise täglich Daten von unseren Partnern. Diese Systeme verwenden FTP für den Transfer, weshalb wir einen eigenen FTP-Server (vsftp) betreiben müssen. Der Zugriff wird mehrstufig abgesichert:

  1. Firewall-Regeln, die den Dienst auf das Subnetz des Partners einschränken
  2. FTP-Zugriff auf die entsprechenden User einschränken. Dazu wird die vsftp.conf um folgende Einträge ergänzt:
    userlist_deny=NO
    userlist_enable=YES
    userlist_file=/etc/vsftpd.user_list
    

    Das entsprechende /etc/vsftpd.user_list File enthält nur die Benutzernamen der erlaubten FTP-Accounts (einer pro Zeile)

  3. chroot Umgebung für diese User aktivieren. In vsftp.conf wird folgende Zeile hinzugefügt.
    chroot_local_user=YES
    

    Das alleine reicht aber noch nicht aus, zudem muss in /etc/passwd das Heimatverzeichnis der Benutzer angepasst werden:

    ftpupload:x:1001:1001::/mnt/ftpbase/./ftpupload:/usr/sbin/nologin
    

    Das Umschreiben von /mnt/ftpbase/ftpupload auf /mnt/ftpbase/./ftpupload hat zur Folge, dass der User nicht aus dem Verzeichnis /mnt/ftpbase ausbrechen kann.

  4. Andere Zugänge für diese User deaktivieren. Im passwd Ausschnitt oben sieht man außerdem, dass als Shell /usr/sbin/nologin angegeben wird. Dadurch wird der Zugang via SSH für den account gesperrt. Hier gibt es nur einen Stolperstein: Ubuntu führt nologin nicht in der Datei /etc/shells auf. Dadurch funktioniert der Zugriff auch via FTP nicht und vsftp meldet, dass das Passwort falsch ist 🙁
    root@sidi:~# cat /etc/shells 
    # /etc/shells: valid login shells
    /bin/sh
    /bin/dash
    /bin/bash
    /bin/rbash
    /usr/bin/screen
    /usr/sbin/nologin
    
  5. und schließlich läuft auch noch fail2ban mit folgendem Eintrag:
    [vsftpd]
    enabled  = true
    port     = ftp,ftp-data,ftps,ftps-data
    filter   = vsftpd
    logpath  = /var/log/vsftpd.log
    maxretry = 6
    

Unity Application switcher

Nach langem hin und her bin ich jetzt (Ubuntu 13.04 beta) doch auch bei der Ubuntu Unity Oberfläche gelandet, denn unter xfce (xubuntu) gab es auch so manches Problemchen (ich sag nur Sound, Netzwerkmanager, …). Einige Sachen sind gewöhnungsbedürftig, aber was gar nicht geht ist der Unity-application-switcher. Die ALT-TAB Kombination wurde in ihrem Verhalten verändert, worauf ich mich trotz gutem Willen nicht umstellen kann.

Glücklicherweise kann das relativ einfach geändert werden (siehe askubuntu ). Was in der default Installation von Ubuntu allerdings fehlte war das Paket compiz-plugins, das die rettende Option „Static Application Switcher“ enthält. Also apt-get install compiz-plugins und (fast) alles wird gut.

Unity Static Application Switcher

Xfce und xfrun

Die merkwürdigen Userinterface Änderungen der letzten Ubuntu Versionen (Unity) haben mich bereits vor geraumer Zeit bewogen, auf Xfce als Desktop System umzusteigen. Ich bin äußerst zufrieden, da es eigentlich alles beinhaltet, was ich am Desktop benötige. Leider gibt es in der aktuellen Version (Xfce 4.10 in Ubuntu 12.10) ein Problem mit dem Programm-Starter xfrun4 (das jetzt xfce4-appfinder heißt und IMO etwas überladen ist), der über ALT-F2 aufgerufen wird (mehrere Bugreports, zum Beispiel hier).

Nachdem ALT-F2 die von mir am meisten benützte Tastenkombination ist, musste eine schnelle Lösung her: Das verve-plugin integriert sich in ein vorhandenes Panel und ist sehr leichtgewichtig. Trotzdem bietet es eine History, die mit Pfeiltasten abgerufen und TAB ergänzt werden kann. Um die Kommandozeile von der Tastatur aus zu aktivieren muss man den Keyboard-Shortcut ALT-F2 auf das Programm verve-focus legen und los gehts.