Dazu erstellt man z. B. eine ausführbare Datei in /etc/profile.d/, die dann nach dem Login beim Starten der Shell ausgeführt wird.

Loggt sich jedoch jemand nicht direkt in einer interaktiven Shell per SSH ein, sondern nutzt z. B. mit -N die Weiterleitungsfunktion, so erhält man mit der genannten Methode keine Email. Dafür muss man früher ansetzen, beim Login selbst. Hierfür kann man PAM nutzen und es anweisen, eine Email abzusetzen, sobald ein Login im Gange ist.

Dazu nutzt man das Modul pam_exec und übergibt diesem als Argument das aufzurufende Script, welches man selbst erstellt.

Wie das genau funktioniert, steht unter http://blog.th-neumeier.de/2011/02/send-email-on-ssh-login-using-pam/.

Bei normalem SSH muss man sich jedes Mal neu einloggen, sobald sich die IP-Adresse des Clienten ändert.

Nicht so bei Mosh, hier zählt die Client-IP-Adresse für den Mosh-Server überhaupt nichts, der Client authentifiziert sich immer über einen eigenen Schlüssel.

Und so ist es auch egal, ob man von WLAN nach UMTS wechselt, sich der Rechner für eine Stunde schlafen legt und dann wieder per DSL einwählt. Man ist beim Aufbau einer neuen Verbindung mit anderer IP-Adresse immer noch am Mosh-Server eingeloggt.

Verbindungsaufbau

Um eine Verbindung per Mosh aufzubauen, wird zuerst eine SSH-Verbindung zum Server aufgebaut. Über diese Verbindung wird auf dem Server der Mosh-Server gestartet der geheime Schlüssel an den Clienten übermittelt. Dann wird die SSH-Verbindung beendet. Auf dem Clienten wird der Mosh-Client gestartet und verbindet sich per UDP (siehe unten) auf den Mosh-Server und authentifiziert sich diesem gegenüber mit dem vorher übermittelten Schlüssel.

Anstatt diesen gesamten Vorgang über den Clienten erledigen zu lassen kann man sowohl den Mosh-Server als auch den Mosh-Clienten manuell starten, muss dann aber dafür sorgen, dass der Client den richtigen Schlüssel und Port kennt.

Der Mosh-Server benötigt im Gegensatz zu SSH für jeden Clienten einen eigenen Port, angefangen bei 60001.

Reaktionszeit

Selbst über sehr langsame Verbindungen mit einer großen Round-Trip-Time soll Mosh schnell auf Tastatureingaben reagieren, da nicht jedes  Byte vom Server gesendet wird sondern immer nur die aktuelle Bildschirmausgabe.

Eingaben, die noch nicht vom Mosh-Server bestätigt worden sind, werden unterstrichen dargestellt; so kann man weiterschreiben und Texte korrigieren, ohne jedes Mal wie bei SSH darauf zu warten, wann die Eingaben endlich angekommen sind.

Sonstiges

• Mosh benötigt keine Root-Rechte.
• Mosh (Server und Client) gibt es als Pakete für alle möglichen Linux-Distributionen, für OS X, für Cygwin und als Erweiterung für Google Chrome.

…

Eine interessante Ergänzung zu SSH auch wenn ich wegen mangelndem Wissen überhaupt nicht einschätzen kann, ob Mosh sicher ist. Zu diesem Thema gibt es auf Youtube ein paar Videos, die man sich mal angucken sollte…

Der letzte Commit auf der GitHub-Seite ist von Dezember 2014.

Die Projektseite ist hier zu finden.

Danke an Mister n. für den Tipp.

Seit der Internetanschluss bei mir auf DS-Lite umgestellt wurde, bekommen SSH-Verbindungen, bei denen nichts passiert, reproduzierbar zu allen Servern nach ca. fünf Minuten einen Timeout.

Vor der Umstellung kannte ich dieses Problem gar nicht, auch nicht bei anderen Internet Service Providern; SSH-Sitzungen waren auch nach Stunden der Untätigkeit noch da.

Als Fix wurde immer eine tmux-Session betreten, dann hielt die Verbindung auch ewig.

Lösung

Habe gestern darüber mir einem Mensch auf einem Mumble-Server gesprochen, der mit den Tipp gab, dass es Alive-Pakete für SSH gibt …

Tatsächlich steht in der Manpage von ssh_config:

ServerAliveInterval
Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server.  The
default is 0, indicating that these messages will not be sent to the server.  This option applies to protocol version 2 only.

Per Voreinstellung ist der Wert 0 (Null), es werden also keine Alive-Pakete gesendet, wenn nichts passiert. Habe Client-seitig die Variable mit dem Wert 5 in die Datei /etc/ssh/ssh_config eingetragen.

Jetzt geht es wieder, vielen Dank dafür :)

Besonders interessant ist das letzte Beispiel, bei dem bei einem bestimmten Zertifikat ein definiertes Kommando ausgeführt wird.

http://www.debian-administration.org/article/685/Restricting_SSH_logins_to_particular_IP_addresses.

Dies ist z.B. hilfreich, wenn eine Verbindung hängt und man diese trotzdem beenden will.
Meine bisherige Methode war, das Terminal zu schließen.
Die „bessere“ Methode ist, die SSH-Verbindung mit ~. ohne Umwege zu beenden, die Shell ist dann wieder frei :)

Eine Liste der verfügbaren Befehle erhält man mit ~?

Supported escape sequences:
 ~.  - terminate connection (and any multiplexed sessions)
 ~B  - send a BREAK to the remote system
 ~C  - open a command line
 ~R  - Request rekey (SSH protocol 2 only)
 ~^Z - suspend ssh
 ~#  - list forwarded connections
 ~&  - background ssh (when waiting for connections to terminate)
 ~?  - this message
 ~~  - send the escape character by typing it twice

Damit diese Kombinationen funktionieren, muss direkt vorher ein Zeilentrenner (z.B. Enter) eingegeben worden sein.