Schlagwort: ssh

Kurztipp: tmux Session beim login starten bzw. attachen

kero 2 Kommentare

Um beim Login via ssh sofort in einer tmux Session zu landen habe ich folgendes in meine .bashrc auf dem Zielhost eingefügt:

case $- in
    *i*)
    if command -v tmux>/dev/null; then
        if [[ ! $TERM =~ screen ]] && [[ -z $TMUX ]]; then
          if tmux ls 2> /dev/null | grep -q -v attached; then
            exec tmux attach -t $(tmux ls 2> /dev/null | grep -v attached | head -1 | cut -d : -f 1)
          else
            exec tmux
          fi
        fi
    fi
    ;;
esac

Sehr praktisch falls die Verbindung nicht stabil oder die bash_history deaktiviert ist.

Man kann auch

ssh 123.123.123.123 -t tmux a

nutzen, falls eine tmux Session vorhanden ist bzw. „tmux“ falls keine.
Die .bashrc Lösung ist aber natürlich etwas eleganter.

Link:  https://stackoverflow.com/a/42351698

 

sperr mich ein Baby

kero 2 Kommentare

Chroot ist gut, so einfach ist das. Multiusersysteme ohne chroot bieten ein grosses Sicherheitsrisiko. Dieses Risiko entsteht in der Regel durch falsch gesetzte Dateirechte. Leider kann mit vertretbaren Mitteln nicht überall eine chroot Umgebung aufgebaut werden. Generell sollte man sich immer Fragen: Braucht der Benutzer ueberhaupt eine Shell? Nehmen wir einen standard Webserver mit mehreren virtuellen Webservern und unterschiedlichen Benutzern als Beispiel. Der Benutzer will Daten auf den Webserver ablegen, die darüber bereitgestellt werden, mehr nicht. Eine Shell ist dabei voellig unnötig und erhöht nur das Risiko eines potentiellen Einbruchs und der Datenmanipulation (und und und).  Falsch gesetzte Dateirechte sind in einer chroot Umgebung nur „halb so schlimm“. Nehmen wir z. B. die beliebte

-rw-r--r-- 1 thomas thomas 0 2011-07-15 10:22 config.php

Natürlich kann und muss der Webserver die Datei lesen können, aber der Benutzer Satans101 kann die Datei auch lesen und sein teuflisches Werk damit treiben. Nutzt man chroot, schützt man primär die Benutzer voreinander. Ein Einbruch mit ergattern eines Shell Zugangs und Zugriff auf andere Benutzerdaten,  ist so nicht ohne weiteres möglich (ich erspare mir Sachen wie  how-to-get-shell-acces-in-no-mans-land). Ein hervorragender Weg ist dabei die sftp chroot Umgebung von ssh zu nutzen. Vorteil ist man muss keine extra Software installieren und nutzt die Möglichkeiten von ssh. Ganz kurz sieht das in der /etc/ssh/sshd_config etwa so aus:

AllowGroups ssh-allow sftp-allow
Subsystem sftp internal-sftp
Match group sftp-allow
ChrootDirectory /user/home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match

Wichtig dabei ist

chown root:root /user/home/username

Das Userhome muss root gehoeren.
Das ssh-allow ist natuerlich nur Beiwerk, aber sinnig. Dies ist nur eines der Werkzeuge um die Sicherheit zu erhoehen, tools wie chmod g+s, rkhunter, iwatch, aide, tiger, clamav, limits.conf, quota, fail2ban, open_basedir, portchange, diverse selbst geschrieben Skripte usw. helfen dabei auch weiter.

Ganz grob einige Vorteile von croot mit sftp dabei

  • Benutzer sieht Daten anderer Benutzer nicht
  • Benutzer kann keine Prozesse laufen lassen -> Benutzerprozesses fallen sofort auf
  • Geklaute Accounts haben nur einen begrenzten Nutzen für Einbrecher
  • Unerfahrene Benutzer irren nicht durch das gesamte Dateisystem (ja tun sie tatsächlich)
  • …

Nachteile

  • sind zu vernachlässigen

Chroot im Zusammenhang mit sftp nutze ich nun seit über 2 Jahren mit mehreren 100 Benutzern und meine Erfahrungen sind durchweg positiv. Der optimale client dabei ist sshfs. Programme wie fireftp, filezilla, sftp und winscp gehen natürlich auch. Empfehlen kann ich auch eine strickte Trennung der Dienste auf unterschiedliche Systeme, aber wem erzähl ich das, weiß man doch alles.

links: OpenSSH SFTP chroot() with ChrootDirectory