Umgang mit SSH-Keys und Passwörtern bei mehreren Servern

  • Was ja auch nicht nötig gewesen wäre. --user root --ask-pass sind hier Deine Freunde. :)

    Jo, hab ich test weise verwendet, aber hierfür müsste ich das Passwort händisch eingeben, was die schöne Automation ein bisschen behindert. Andere Option wäre das Passwort im Plaintext irgendwo abzuspeichern.

    Fand nach hin und her probieren den SSH Key am praktischsten. Lediglich den SSH Port musste ich in der config ändern. :)

    Meine Produkte: definitiv zu viele, RS, VPS, Domains, Webhosting, ...

  • - 2FA

    - Schutz vor eigener Dummheit


    sind 2 Faktoren, die den Zugang über einen normalen Nutzer für mich sinnvoll machen. Brauche ich root Rechte kann ich mir diese nehmen, arbeite dann aber auch bedachter. Unter dem normalen Nutzer kann ich nichts kaputt machen.

    Zum Thema SSH weltweit offen kann ich nur sagen: Port ändern. Seit ich meinen SSH überall auf nem anderen Port laufen hab ist das log für failed auths leer.

    Kann ich auch bestätigen, ich finde da nur meine Vertipper beim Passwort :).


    Root-Login würde ich auch immer deaktivieren. einen Ussernamen zu erraten, der die Berechtigung hat, sich root Rechte z. B. via sudo zu geben + dessen Passwort ist deutlich schwierigker als nur das Passwort des root-Users.


    Den IP-Bereich schränke ich nicht ein, da ich nicht weiß, von wo aus ich evtl. doch noch zugreifen möchte.

  • Bin ich der Einzige, der hauptsächlich auf das gute alte Passwort und nen geänderten SSH Port zurückgreift?

    Hab ich auch ne Zeit lang gemacht bis mir auffiel wie praktisch SSH-Keys sind. Unter MacOS werden die Schlüssel für die Private Keys vom ssh-agent im Schlüsselbund abgelegt und ich muss nichts weiter tun als ssh sX.meinedomain.de einzutippen.

  • ich hab eine zentrale VM im LAN,

    von der aus ich mich via SSH auf allen meinen Linux-Systemen anmelde


    mir ist nämlich was geniales aufgefallen:


    verbinde ich mich z.B. via PuTTY auf einen meiner vServer (mit IPv4),

    dann werde ich mangels Aktivität innerhalb sehr kurzer Zeit 'rausgeworfen;

    mache ich das hingegen über diese VM (mit IPv6)

    bleibt die Verbindung bestehen und es gibt auch keinen 'Rauswurf ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Bei mir ist der Root-Login über SSH immer deaktiviert, und zusätzlich als 2FA-Faktor mittels libpam-google-auth abgesichert.

    Das Ding ist Klasse! Leider habe ich darauf auch ganz vergessen in meinem Beitrag. Das nutze ich für einige besonders schützenswerte SSH-Zugänge, z.B. vom KVM-Hostsystem oder Backupsysteme, die auf viele andere Systeme Zugriff haben. Trotz Keyfiles ist das ein netter Zusatz.

    verbinde ich mich z.B. via PuTTY auf einen meiner vServer (mit IPv4),

    dann werde ich mangels Aktivität innerhalb sehr kurzer Zeit 'rausgeworfen;

    Dann konfiguriert Deinen SSH-Client richtig! :P :D


    Stichwort Keepalive. Das kennt sogar PuTTY.… ;)

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Dann konfiguriert Deinen SSH-Client richtig! :P :D


    Stichwort Keepalive. Das kennt sogar PuTTY.… ;)

    Du weißt schon, daß der richtig konfiguriert sein muss, weil ich mich ja via PuTTY auf diese VM im LAN verbinde (mit IPv4)

    und da eben nicht rausgeworfen werde ...:P:D

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Man kann es afaik am Client oder Server konfigurieren, oder an beiden Stellen.


    mainziman Und ich schätze mal, dass Du im LAN kein NAT bzw. zig Router dazwischen hast. Das nur als eines von vielen Beispielen, warum inaktive TCP-Verbindungen übers Internet abbrechen können. Insofern ist Dein Vergleich leider nicht passend.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • KB19 mit IPv4 sind es 2 NAT Router dazwischen und mit IPv6 nur 1 Router (zwischen LAN-Prefix und Tunnel-Prefix);

    der innere NAT Router ist ident mit dem Router zwischen IPv6-LAN-Prefix und IPv6-Tunnel-Prefix;

    darum nur logisch, daß eine SSH-Verbindung mit PuTTY zur oben erwähnten VM mit IPv4 nicht abbricht, ergo sind dort

    Client (PuTTY) als auch Server (VM im LAN) korrekt konfiguriert

    und per ssh in der VM zum vServer mit IPv6 bricht ebenso nicht ab, ergo sind auch der

    Client (VM) als auch Server (vServer) korrekt konfiguriert;

    hingegen PuTTY zum vServer bricht ab, weil 2 NAT-Router dazwischen;

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • Da können 10 NAT dazwischen sein. Wenn sich dort nicht die Uplink-IP ändert oder das Ding extrem komisch arbeitet, dürfte es mit Keepalive (am Besten auf TCP und Anwendungsebene) im Bereich von 30-120 Sekunden keine Probleme geben.


    Du vergleichst in Deinem Beitrag Äpfel mit Birnen. Für mich erscheint Deine Schlussfolgerung absolut nicht logisch. Aber vielleicht fehlen mir dazu Details, die ich mit den von Dir gelieferten Informationen nicht herauslesen kann. Ich glaube nach wie vor, dass Dein Umweg über die VM unnötig ist.


    Ist aber prinzipiell eh egal. Mit dem Topic hat das eher nichts zu tun.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • das kann ich für das Playbook verwenden, dass die SSH Keys installiert und den SSH Dämon absichert

    Ja genau dafür nutze ich das auch. Schau Dir auch mal die ganzen "become" Argumente an. Man kann so die komplette Authentifizierung, selbst wenn man den Umweg über sudo gehen muss via Argumente machen. Für das "Aufnahme-Playbook" sehr praktisch.

  • Ja genau dafür nutze ich das auch. Schau Dir auch mal die ganzen "become" Argumente an. Man kann so die komplette Authentifizierung, selbst wenn man den Umweg über sudo gehen muss via Argumente machen. Für das "Aufnahme-Playbook" sehr praktisch.

    Die Maschinen, die ich mit Ansible einrichten, haben initial alle entweder root mit Passwort oder den Ansible SSH Key drauf. Damit kann ich dann den Rest konfigurieren.


    „become“ kannte ich ich bisher nicht. Ich muss mal bei meinen Playbooks gucken ob ich das verwenden kann. Ich automatisiere im Moment hauptsächlich root Aufgaben.

  • Da können 10 NAT dazwischen sein. Wenn sich dort nicht die Uplink-IP ändert oder das Ding extrem komisch arbeitet, dürfte es mit Keepalive (am Besten auf TCP und Anwendungsebene) im Bereich von 30-120 Sekunden keine Probleme geben.

    jetzt wo Du es sagst, mit PuTTY (weil IPv4 und NATs dazwischen) kommt nach rund 120 Sekunden Inaktivität ein 'Rauswurf, mit ssh (weil IPv6) eben nicht - der Host hat kein IPv6(!) ist IPv4only, die VM ist DualStack;

    eine SSH-Verbindung von der VM mit ssh über IPv4 wird ebenfalls nach kurzer Zeit der Inaktivität beendet;

    es geht hier eher um SSH via IPv4 vs SSH via IPv6 ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • es geht hier eher um SSH via IPv4 vs SSH via IPv6 ...

    Klar, weil IPv6 normalerweise kein NAT hat… 8)


    Ich tippe nach wie vor darauf, dass Du im SSH-Client keinerlei Keepalive-Features aktiviert hast. Sonst würde es diesen Unterschied nicht geben. Per Default sind die nämlich immer deaktiviert, da TCP-Verbindungen von sich aus trotz Inaktivität mehrere Tage bis Wochen überleben würden – solange die Anwendungen keine eigenen Timeouts haben. Nur unterstützt das verständlicherweise kaum ein NAT-Gateway oder eine Firewall. Je schneller man Verbindungen aus dem Connectiontracking streichen kann, umso schneller hat man wieder Ports für andere Verbindungen frei.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Bei mir wird eigentlich alles durch UFW verboten. Außer die Dienste die erreichbar sein müssen. Ich gebe lediglich die IPs der anderen Server und meine IP zu Hause frei.

    Die ist quasi statisch, da an die Mac vom Router gebunden. Sollte sich hier einmal etwas ändern, geb ich am Master von tinc die neue IP frei und darf wieder alles. :)


    Root Login via SSH Keys ist bei mir auch aktiv, jedoch wie erwähnt nur über meine eigene IP.


    lg.