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

[Ein ehemaliger Benutzer]

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.

[Ein ehemaliger Benutzer]

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

[Ein ehemaliger Benutzer]

@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....

[Ein ehemaliger Benutzer]

@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.

[Ein ehemaliger Benutzer]

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.