ssh-Login aufhübschen

  • ssh-Login aufhübschen

    Um hier nicht nur Fragen zu stellen, möchte ich den Wissenspool hier etwas mit erweitern.
    Heute habe ich mich für das optische Aufhübschen beim ssh-Zugriff entschieden.

    Dieser Beitrag ist im Laufe der Zeit, dank den Hinweisen, etwas umgeschrieben worden.

    1. Ausgaben vor dem Login
    2. Ausgabe beim Login
    2.1 motd (Message of the day)
    2.1.1 update-motd.d-Skripte
    2.1.2 Dann noch der Inhalt von /etc/motd
    2.1.3 Demo
    2.2. weitere Möglichkeiten

    1. Ausgaben vor dem Login

    Es ist immer wieder schön, wenn der Rechner bei einer ssh-Anfrage sich vorstellt. Falls man sich vertippt hat und damit den falschen Rechner erwischt, wird es einem dann (meistens) gewahr.
    Diese Meldung nennt sich bei ssh Banner.
    Ein Blick in die /etc/ssh/sshd_config gibt Aufschluß:

    Code
    sudo grep -i 'banner' /etc/ssh/sshd_config
    # no default banner path
    #Banner none

    Kein Banner definiert.
    Die Meldung, die ausgegeben werden soll, wird in eine Datei geschrieben. Ich verwende dafür traditionell /etc/ssh/mblt.

    Code
    sudo touch /etc/ssh/mblt
    sudo chmod 644 /etc/ssh/mblt

    Dann mit dem Editor Eurer Wahl die Meldung, die Ihr ausgeben wollt, in die Datei schreiben.
    Ich habe immer sinngemäß folgendes drin:

    Nach einem Hinweis sei erwähnt, daß das Banner von jedem, der auf dem Rechner übers Netz zugreifen kann, diese Meldung lesen kann. Also NICHT den Benutzernamen und oder das Passwort da reinpacken!

    Code
    ===============================
    Login to: hostname.in-addr.arpa
    -------------------------------

    Und jetzt noch das Ganze in der /etc/ssh/sshd_config aktivieren:
    (am besten ist es, die folgende Zeile unter #Banner none zu schreiben; bei Verwendung anderer Dateinamen, diese entsprechend anpassen)

    Code
    #Banner none
    Banner /etc/ssh/mblt

    2. Ausgabe beim Login

    Hier kann man seiner Phantasie freien Lauf lassen und hat dafür verschiedene Möglichkeiten. Zum einen über /etc/motd, der zentralen /etc/ssh/sshrc oder ganz individuell für jeden User, der in seinem Home-Verzeichnis eine ~/.ssh/rc anlegt. Vielleicht gibt es auch noch mehr Möglichkeiten.

    2.1 motd (Message of the day)

    Um motd nutzen zu können, muß man sicherstellen, das ssh pam nutzt und motd in pam aktiviert ist.

    Code
    $ grep -i 'usepam' /etc/ssh/sshd_config
    UsePAM yes
    $ grep motd /etc/pam.d/sshd 
    # This includes a dynamically generated part from /run/motd.dynamic
    # and a static (admin-editable) part from /etc/motd.
    session    optional     pam_motd.so  motd=/run/motd.dynamic
    session    optional     pam_motd.so noupdate

    Wenn in der /etc/pam.d/sshd motd deaktiviert ist, kann man in der /etc/ssh/sshd_config durch Änderung des Wertes PrintMotd no auf PrintMotd yes die Ausgabe der (reinen) Textdatei /etc/motd erzielen. Wenn allerdings in der /etc/pam.d/sshd motd akiviert ist, sollte PrintMotd auf no stehen, da sonst diese Datei zweimal angezeigt wird. Das ist (zumindest in Bookworm) die Default-Einstellung.

    2.1.1. update-motd.d-Skripte

    Der Vorteil von motd ist, das die auch beim lokalen Login über tty/pts angezeigt werden können. Darauf gehe ich hier aber nicht ein.

    Zuerst werden die Skripte, die unter /etc/update-motd.d liegen abgearbeitet und dann wird der Inhalt von /etc/motd angezeigt. Und wenn Ihr es nicht abgeschalten habt, wird noch der Lastlogin angezeigt.

    Da es relativ simpel ist, mache ich das mal selbsterklärend (einiges geht sicher besser):

    2.1.2. Dann noch der Inhalt von /etc/motd

    Die ASCII-Art läßt sich mit figlet oder irgend einem ASCII-Art-Generator im Web erzeugen.

    Danach wird noch der Lastlogin ausgegeben.
    Wers nicht mag, kann es abschalten. Ich finde es allerdings nützlich.

    Code
    sudo grep PrintLastLog /etc/ssh/sshd_config
    #PrintLastLog yes

    Lastlog ausschalten:

    Code
    PrintLastLog no

    Jetzt den Daemon noch neu starten und dann sollte der ssh-Login hübscher und informativer sein.

    Code
    sudo service ssh restart

    2.1.3. Demo

    Und so sieht das bei meinem Pi 3B+ aus:

    2.2. weitere Möglichkeiten

    Es wurde in der Diskussion zu diesem Artikel noch auf die /etc/ssh/sshrc bzw. die Usereigene ~/.ssh/rc hingewiesen. Was in gewissen Grenzen ebenfalls funktioniert. Aber eine Aussage in der man 8 ssh unter SSHRC hat mich dazu bewogen, hier nicht darauf einzugehen. Da steht, daß der Hauptzweck dieser Datei darin besteht, alle Initialisierungsroutinen auszuführen, die erforderlich sind, bevor das Home-Verzeichnis des Benutzers zugänglich wird. Und der entscheidende Punkt für meine Entscheidung ist:
    Wenn die Datei ~/.ssh/rc existiert, führt sh(1) sie aus, nachdem es die Umgebungsdateien gelesen hat, aber bevor es die Shell oder den Befehl des Benutzers startet. Es darf keine Ausgabe auf stdout erzeugen; stattdessen muss stderr verwendet werden.
    Der Vorteil von ~/.ssh/rc ist, wenn man keine Adminrechte hat, kann man sich entsprechendes basteln.
    Edit (15.0.6.24): Je nachdem, was in der rc steht, funktioniert bei mir dann scp nicht mehr.

    Man kann auch die ~/.profile dafür mißbrauchen, in dem man am Ende folgendes Konstrukt anfügt:

    Code
    if [ -n "$SSH_CONNECTION" ] ; then
    		# was ich so angezeigt bekommen möchte
            echo "SSH_CONNECTION $SSH_CONNECTION"
            # oder ein Skript aufrufen
            if [ -x $HOME/.ssh/meinMOTD.sh ] ; then
            	$HOME/.ssh/meinMOTD.sh
            fi
    fi

    Sicherlich gibt es noch mehr Möglichkeiten, aber ich möchte es bei dem Genannten bewenden lassen.

  • Sehr schoenes Tutorial zum ssh Login :thumbup:

    Wenn man auf mehreren Systemen parallel rumturnt sieht man die netten ssh Begruessungen leider nicht mehr :( PS1 ist der Standardprompt der Konsole. Ueblicherweise wird der User sowie der Hostname angezeigt.

    Wenn man besonders kritische Systeme hat wo man besonders aufpassen sollte kann man den PS1 entspechend auffaellig aendern - z.B. den Hintergrund des PS1. Auch kann man den Hintergrund der Konsole z.B. auf rot aendern.

    Nur so als Idee Dein Tutorial noch zu erweitern ;)

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

  • Danke.

    Nunja, ich nutze zum rumhüpfen screen.

    Jeder Rechner hat seine eigene .screenrc - die sind farblich verschieden. Produktivsysteme sind farblich auffällig gestaltet. Man kann auch screen in screen ausführen, ist allerdings etwas tricky.

    Das sieht bei mir z.B. so aus:


    Achja, und screen läuft auf dem Rechner weiter, wenn man die Verbindung verliert und man kann von jedem Rechner der Welt, der ssh kann und den Rechner erreicht, an sich ziehen. Neben netcat ist screen (tmux) ein Pflichttool am Schweizer Taschenmesser.


    pi3 | 13-03-24 21:17 | 0* bash

  • Lust habe ich schon. Allein, weil ich seit ca. 20 Jahren eine unfertige screen-Anleitung in meinem TODO habe.

    Das ist schon fertig:

    1. Vorwort
    2. Konfiguration
    3. Arbeiten mit Screen
    3.1 Zur allgemeinen Bedienung
    3.2 Terminal locken und Screen detachen
    3.3 Ereignisse
    3.3.1 Meldung bei Ruhe
    3.3.2 Meldung bei Aktivität
    3.4 Fenster splitten

    dieses ist noch unfertig:

    3.5 Kopiermodus
    3.5.1 Der Puffer
    3.5.2
    3.6 Hardcopy
    3.7 Datenaustausch

    und das steht im TODO

    Themen: (lose Folge)
    - Fenstersplit mit resize
    - Kopiermodus
    - Multiusermodus
    - Screenshot / Hardcopy/log
    - Textaustausch über /tmp
    - hängendes Fenster killen
    - Ereignisse: monitor, silence, message (lastmsg, bell)
    - lock screen, alle detached varianten, -noch--> kill+quit
    - verschachtelte sessions
    - digraph (umlaute b.s. strg-a strg-v a" --> ä)
    - die verschiedenen Programmstarts
    - Tastenbindungen
    - Hinweis Dokumentation
    - Lizens
    - Kommandozeile
    - zombie-modus (strg-a : zombie z)

    Ich muß die wirklich mal fertig schreiben. Evtl. als Mehrteiler, so das wenigstens der fertige Teil einen Nutzen über meinem Netzwerk hinaus haben kann.

    Wobei tmux wohl mächtiger ist, aber ich nutze screen seit über 20 Jahren. Da bleibt man irgendwie kleben.

  • 1. Ausgaben vor dem Login

    ... würde ich allerdings wirklich nur im Heimnetz nutzen, denn in gewisser Weise stellt das ein Sicherheitsrisiko dar, zumindest wenn ein Skriptkiddie am Werk ist. Oder den Zielen interne, anderen unbekannte Namen geben, die dann angezeigt werden.

    BTW: Ich bin eher ein Freund von tmux, aber das nur am Rande. :bussi2:


    //Edit: Hat sich überschnitten... tmux hattest Du ja nun auch bereits erwähnt.

  • Nunja, wenn host $ip das gleiche ausgibt, wie das Banner von ssh, gibt es kein Sicherheitsrisiko.

    Aber Du hast recht, man sollte sich überlegen, was man in das Banner packt.

    BTW: dann bist Du wohl mindestens 10 Jahre jünger als ich. ;)

  • Bergwichtel Ich wollte hier nicht Dein Tut mit - auf den Tut Inhalt bezogenen Beitraegen zerreissen - also gewissermassen Tut OT zu sein. Sorry.

    hyle Bzgl Tuts komme immer mal wieder nuetzliche Kommentare und leider auch unnuetzliche Kommentare. Siehst Du keine Moeglichkeit einem jeden Tutorialersteller nahezulegen einen zweiten Thread zu erstellen wo Kommentare zu dem Tut zu plazieren sind? Dadurch wird das Tut nicht zerfleddert fuer jemandem der dem Tut folgt.

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

  • Nunja, wenn host $ip das gleiche ausgibt, wie das Banner von ssh, gibt es kein Sicherheitsrisiko.

    Dann kann man sich doch aber Banner auch gleich schenken oder? ;)

    BTW: dann bist Du wohl mindestens 10 Jahre jünger als ich. ;)

    Kann schon sein, weiß ich nicht. Alter ist eh nur eine Zahl.

  • Siehst Du keine Moeglichkeit einem jeden Tutorialersteller nahezulegen einen zweiten Thread zu erstellen wo Kommentare zu dem Tut zu plazieren sind?

    Ich wüsste nicht wie man das machen könnte. Da gibt es leider nicht viele Möglichkeiten und keine davon wäre automatisiert.

    Wenn es ein Tutorial mit mehreren aufeinander folgenden Beiträgen ist, dann käme nur eine Absprache des TO mit einem Mod in Frage. Sperren > öffnen für den nächsten Part > Sperren usw.

    Bei einem "Oneshot" wie hier kann man ggf. hinterher nur auslagern.

    Eine Mischung aus beidem war übrigens der Wie frage ich nach Hilfe? Thread. ;)

  • Bei einem "Oneshot" wie hier kann man ggf. hinterher nur auslagern.

    Das habe ich schon im Hinterkopf :) Nur erfordert dass in meinen Augen unnuetze Aktionen deinerseits. Woltlab hat doch so viele Plugins. Gibt es da nicht eines welches vor der Erstellen eine Beitrags in einem Forum - also hier dem Tutorialforum - eine Seite vorschaltet wo auf sowas hingewiesen wird?

    ps915 FYI

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

  • framp zu \@hyle

    > Moeglichkeit einem jeden Tutorialersteller nahezulegen einen zweiten Thread zu erstellen wo Kommentare zu dem Tut zu plazieren sind

    Das wäre eine generell gute Idee. Tutorials mit einem extra Diskussionthread zu begleiten. Das hilft dem Tutorial und vor allem den Lesern.

    framp

    > Ich wollte hier nicht Dein Tut mit ... zerreissen

    Ich sehe das nicht negativ. Vieles ist durch Hinweise, Tips, Anmerkungen für alle zu verbessern. Drum auch mein Kommentar zu Deinem Hinweis für hyle.


    hyle

    >> Nunja, wenn host $ip das gleiche ausgibt, wie das Banner von ssh, gibt es kein Sicherheitsrisiko.
    > Dann kann man sich doch aber Banner auch gleich schenken oder?

    Finde ich nicht, ich habe schon ab und an den falschen Namen des Zielrechners für den ssh-Login eingegeben. Dank der Meldung sehe das gleich. Spätestens nach dem ersten Fehlversuch.

  • Erstellen eine Beitrags in einem Forum - also hier dem Tutorialforum - eine Seite vorschaltet wo auf sowas hingewiesen wird?

    Dazu kann ich nur auf den fetten Hinweis oben verweisen, der im Tutorial-Bereich angezeigt wird, den aber trotzdem viele User einfach ignorieren.

    Das würden ziemlich sicher auch Verfasser von Tuts übersehen.

    BTW: Den OT hier werde ich morgen Abend erst auslagern. Heute hab ich keine Nerven mehr dazu.

  • Finde ich nicht, ich habe schon ab und an den falschen Namen des Zielrechners für den ssh-Login eingegeben. Dank der Meldung sehe das gleich.

    Das stimmt schon und deshalb schrieb ich

    Oder den Zielen interne, anderen unbekannte Namen geben, die dann angezeigt werden.

    Damit man das nicht verwechselt. ;) Das muss ja nun nicht gleich der Hostname sein.

  • Dazu kann ich nur auf den fetten Hinweis oben verweisen, der im Tutorial-Bereich angezeigt wird, den aber trotzdem viele User einfach ignorieren.

    :wallbash: Aber vielleicht lesen 10% der Ersteller den Hinweis und verweisen dann im ersten Posting auf den Kommentarthread zu dem Tut. Wenn den Link auch nur 10% lesen - reduziert das ein wenig die OTs in den Tutorials. Aber ich verstehe dass sowas nur mit einem Forenplugin zu bewerkstelligen ist,

    Und ja ich verstehe dass ewiges Verschieben nervig ist :fluchen:

    :no_sad: ... Kein raspiBackup - kein Mitleid ... :no_sad:

    Mein Raspberry Zoo

    3 * RPi1B, 2 * RPi3B, 2 * RPI4, 1 * CM4, 1 * RPi5

  • hyle Ich weiß was Du meinst, aber ich halte das beste Argument, das es gibt, dagegen. Man verwendet bei einem Banner nur Informationen, die ohne Probleme sowieso zu ermitteln wären. Jede andere Information kann zu einem (wirklichen) Sicherheitsrisiko werden, da aus diesen Zusammenhänge geschlussfolgert werden können. Ergo, zeige ich das als Banner, was eh schon jeder weiß oder ermitteln kann.

  • Und so sieht das bei meinem Pi 3B+ aus:

    Das geht auch einfacher mit einer einzigen Datei.

    /etc/ssh/sshrc

    Die wird automatisch beim ssh-Start aufgerufen.

  • Franjo G Das sieht gut aus und ich habe auch das Gefühl, das dies einen Zacken schneller geht.

    Zu meiner Schande muß ich gestehen, das ich mich (vermutlich) noch nie mit /etc/ssh/sshrc beschäftigt habe. Aber man ist so gewohnheitsmäßig und beim Aufsetzen eines neuen Systems kommt das natürlich zum tragen.

    Danke für den Hinweis. Ich werde in naher Zukunft℠ mich einlesen und evtl. einen Hinweis auf eine andere Möglichkeit als mot.d oben reinschreiben.

    Aber vorher wird wohl ein erster Teil meiner screen-Anleitung im Forum erscheinen. Der wartet schon 20 Jahre auf Veröffentlichung. ;)

  • Zu meiner Schande muß ich gestehen, das ich mich (vermutlich) noch nie mit /etc/ssh/sshrc beschäftigt habe

    Die sshrc wird genauso abgearbeitet wie die bashrc. Du kannst natürlich auch alles in die bashrc schreiben, aber so ist es "sauberer".


    Hier mal der Code zu obigem Beispiel:

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!