Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!

Hallo, mich nervt das etwas... Ich verbinde mich via SSH mit Webserver, dazu muss ich ein Passwort eingeben, das kopiere ich vorher in die Zwischenablage... Bei jedem sudo-Aufruf muss ich das Passwort wieder eingeben usw.

Würde es Sinn machen, zu versuchen, einen eigenen SSH-Client zu implementieren, der das Passwort automatisch einfügt?
Könnte man einen Shortcut programmieren, der eine bestimmte Zeichenkette in die Zwischenablage legt, und nach dem Einfügen sofort wieder entfernt?
Wie geht ihr "professionell" (zum Beispiel als Netzwerkadministratoren) mit Passwörtern um? Ich denke mal nicht, dass unter der Tastatur ein Zettel liegt, oder? Also... wie merkt sich zum Beispiel Elon Musk das Passwort für seinen Twitter-Account?

Leon0402

Die selbe Frage hatte ich mir auch gestellt. Deswegen habe ich gestern Elon beim Mittagessen gefragt wie er sich sein Passwort für seinen Twitter Account merkt. Er nutzt https://keepassxc.org/. Besonders gefallen hat ihm, dass ihm der Passwort Manager daraufhin gewiesen hat, dass sein bisheriges Passwort "elon-musk-ist-der-geilste" kein starkes Passwort ist. Er konnte sich dann ganz einfach ein sicheres Passwort generieren lassen.

Würde es Sinn machen, zu versuchen, einen eigenen SSH-Client zu implementieren, der das Passwort automatisch einfügt?

Nein.

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Bei jedem sudo-Aufruf muss ich das Passwort wieder eingeben usw.

Je nach genauen Anforderungen gibt es da verschiedene Möglichkeiten, sein Passwort nicht so häufig einzugeben. ssh-agent ist z.B. eine Möglichkeit, wenn es dir jetzt um das passwort für deinen ssh Schlüssel geht. Das ging jetzt aus deinem Text nicht so ganz hervor.

ja, aber ich brauche was für windoof

Prinzipiell ist doch jedes Passwort, das man sich selber merken kann, schlecht... Also, wie merkt man sich das Keepass-Passwort?!

https://tenor.com/Gxh8.gif

SeppJ

ssh-agent wurde schon genannt, aber noch besser public key Verfahren aufsetzen.

warum nicht gleich ssh certs, dann sparst dir das passwort fuer den key.

Quiche Lorraine

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Prinzipiell ist doch jedes Passwort, das man sich selber merken kann, schlecht...

https://xkcd.com/936/

SCNR

@Cardiac sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

warum nicht gleich ssh certs, dann sparst dir das passwort fuer den key.

Sudo? Denken, schreiben, posten - nicht umgekehrt.

mhm....bist du EinNutzer0? Oder einer der anderen beiden spinner, Sarkast/titan99_

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Sudo? Denken, schreiben, posten - nicht umgekehrt.

ssh-client selbst implementieren damit man sich das passwort spart? Denken, schreiben, posten - nicht umgekehrt.

unabhaengig davon, kerberos + ldap wenn es um server geht, ansonsten password manager deiner wahl. keepassxc ist meine persoenliche wahl.

Du hast von certs gesprochen ... jetzt auch noch Alzheimer?

Finnegan

@SeppJ sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

ssh-agent wurde schon genannt, aber noch besser public key Verfahren aufsetzen.

@Fragender: Genau das, und dann gibt es auch noch Dinge wie SSH Agent Forwarding und pam_ssh_agent_auth, womit sich Linux User auch lokal gegenüber SSH Keys authentifizieren lassen. Ich habe mit der Kombination meine Server so eingerichtet, dass ich lediglich beim Start des SSH Agent einmal mein Passwort für den Private Key benötige. SSH-Login und sudo brauchen dann beide kein Passwort mehr.

Ganz ohne Passwort ginge wohl mit nem Security Token das man mit SSH Agent verwenden kann. Yubikey oder ähnliche ... hab mir vor ner Weile nen Nitrokey 3 bestellt, damit aber bisher noch nicht viel gemacht, daher kann ich da noch nicht viel drüber berichten. Sollte aber funktionieren.

SSH keys/PAM hab ich aktiviert

und ich nutze https://mobaxterm.mobatek.net/

und ich hab das nervige sudo Passwort entfernt: https://askubuntu.com/questions/281074/can-i-set-my-user-account-to-have-no-password und https://askubuntu.com/questions/147241/execute-sudo-without-password

jetzt werde ich fast gar nicht mehr nach 'm pwd gefragt

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Du hast von certs gesprochen ... jetzt auch noch Alzheimer?

Nein, nur wesentlich mehr kompetenz als du
https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Certificate-based_Authentication

nervige passwort

weia....

@Cardiac sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Nein, nur wesentlich mehr kompetenz als du

Nö, du hast offenbar keine Ahnung und bist frech ... liest noch nicht einmal das Geschriebene. 5, setzen, hätte man früher in der Schule gesagt. Also beim nächsten Mal: einfach meine Themen nicht beachten. Thx.

Finnegan

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

und ich hab das nervige sudo Passwort entfernt: https://askubuntu.com/questions/281074/can-i-set-my-user-account-to-have-no-password und https://askubuntu.com/questions/147241/execute-sudo-without-password

die NOPASSWD-Lösung funktioniert zwar auch, ist aber nicht das, was ich verwende oder überhaupt empfehlen würde. Da gibt es ein PAM-Modul namens pam_ssh_agent_auth, mit dem bei einer Authentifizierung via SSH Agent gegen den privaten Key des Users geprüft wird. Das erfolgt dann über die laufende SSH-Verbindung mit SSH Agent Forwarding gegen den privaten Key auf deinem Rechner.

Den Ansatz halte ich für deutlich sicherer - NOPASSWD macht deinen User nämlich effektiv zu root. Ein Angreifer kann damit, wenn er unter deiner User-ID Befehle absetzen kann, ebenfalls Kommandos absetzen, die root erfordern. Mit pam_ssh_agent_auth wäre das nicht möglich, da in dem Fall nochmal gegen deinen privaten Schlüssen geprüft wird, den der Angreifer wahrscheinlich nicht hat.

Frag mich aber nicht nach Details, wie man das genau einrichtet, das ist schon ne Weile her und das müsste ich selbst auch wieder recherchieren

SeppJ

@Finnegan sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Den Ansatz halte ich für deutlich sicherer - NOPASSWD macht deinen User nämlich effektiv zu root. Ein Angreifer kann damit, wenn er unter deiner User-ID Befehle absetzen kann, ebenfalls Kommandos absetzen, die root erfordern.

An andere Mitleser: Kein Passwort für sudo ergibt eigentlich nur Sinn (dann aber auch gleich sehr viel), wenn man sich nur per key-auth zu dem Nutzer anmelden kann (oder Zerifikate und andere passwortlose Verfahren auch). Was effektiv gleichwertig ist zu dem, was du mit pam_ssh_agent_auth beschreibst.

Man muss doch ohnehin darauf vertrauen, dass das System insgesamt nicht kompromittiert ist... Also nicht nur ein einzelner Benutzer... Dann braucht man sich um die Schadensbegrenzung keine Gedanken machen.

Beispiel: Du hast ein Haus mit einer verschlossenen Haustür, dann würdest du doch auch nicht noch eine Mauer und Wassergraben außen drumherum bauen, damit die Auswirkungen nicht so schlimm sind, wenn ein Einbrecher zwar die Mauer überwindet, jedoch nicht den Wassergraben...

Tyrdal

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Man muss doch ohnehin darauf vertrauen, dass das System insgesamt nicht kompromittiert ist... Also nicht nur ein einzelner Benutzer... Dann braucht man sich um die Schadensbegrenzung keine Gedanken machen.

Beispiel: Du hast ein Haus mit einer verschlossenen Haustür, dann würdest du doch auch nicht noch eine Mauer und Wassergraben außen drumherum bauen, damit die Auswirkungen nicht so schlimm sind, wenn ein Einbrecher zwar die Mauer überwindet, jedoch nicht den Wassergraben...

Wie wäre es zusätzlich mit Fenster schließen?

Finnegan

@Fragender sagte in Webserver, sudo, ssh client usw. - richtiger Umgang mit Passwörtern!:

Man muss doch ohnehin darauf vertrauen, dass das System insgesamt nicht kompromittiert ist... Also nicht nur ein einzelner Benutzer... Dann braucht man sich um die Schadensbegrenzung keine Gedanken machen.

Beispiel: Du hast ein Haus mit einer verschlossenen Haustür, dann würdest du doch auch nicht noch eine Mauer und Wassergraben außen drumherum bauen, damit die Auswirkungen nicht so schlimm sind, wenn ein Einbrecher zwar die Mauer überwindet, jedoch nicht den Wassergraben...

Es ist richtig, ein System bereits als kompromittiert anzusehen, wenn ein Angreifer bereits Rechte eines normalen Users hatte. Das heisst aber nicht, dass man dem Angreifer dann auch gleich maximale Rechte einräumen sollte. Wenn man die User-Berechtigungen restriktiv genug gestaltet, dann reduziert man damit nämlich den potentiellen Schaden eines solchen Angriffs.

Ich sehe das eher als mehrere Verteidigungsringe um meine Festung, und ja, da gehört auch ein Wassergraben dazu. Es ist schon eine ziemliche Hürde nach dem initialen Angriff auch erstmal noch eine Rechteausweitung auf root hinzubekommen. Solche Exploits gibts nicht im Supermarkt am Grabbeltisch - im Gegensatz zu solchen, die "normale" Userrechte gewähren, bei all den zusammengeschusterten Webanwendungen.

Ich lasse Dienste wie Webserver sogar noch in einem unprivilegierten LXC-Container laufen. Wenn sich da jemand root ergattert, und es auch noch schafft aus dem Container auszubrechen, stellt er fest, dass er auf dem darüber liegenden System nur eine User-ID hat, die so ziemlich gar nichts darf - und da hinter ist das Ding nur ein Gastsystem unter einem Hypervisor. Ganz schön Arbeit, wirklich die volle Kontrolle über die physische Hardware zu bekommen ... diese Verteidigungsringe machen schon Sinn, vor allem wenn man die tatsächlich sensiblen Daten, die man schützen will, nicht gleich hinter dem ersten Ring liegen hat.