Wechsel des Passworts unter Linux - auf Kommandozeile...

[chiemsee]

Servus,

hab ein T420 und da ist Ubuntu v. 23xy drauf ::

Das war bereits eingerichtet als ich das Notebook übernommen hab. Alles okay so weit. Das Passwort lautet schlicht "ubuntu"

Frage: kann ich irgendwo einen Wechsel des Passworts vornehmen - auf Systemebene nehm ich mal an!?

VG
PS. bin ein großer Fan von dem T420. Hab noch nie so ein robustes Gerät gehabt - die Tastatur u. das Gehäuse - nahezu unverwüstlich.
Auch mein anderes NB - ein T520 - robust, zäh und praktisch unverwüstlich.

 

[Satrap]

wenn du eingeloggt bist, mache den Terminal auf und tippe passwd ein. dann dein aktuelles Passwort und 2x neues Passwort.

 

[chiemsee]

Servus Strap - vielen Dank für dein rasches Feedback.

Super das werde ich machen.
Viele Grüße u. noch einen schönen Abend.
Chiemsee

 

[horst_lafer]

Du kannst es auch direkt mit einem Kommando ändern:

echo "user:password" | chpassw

 

[preisi]

Vermutlich etwas spät, aber bitte nicht diese Lösung verwenden (auch wenn sie funktioniert).
Passwörter direkt als Teil von irgendwelchen Befehlen/Befehlsketten zu schreiben ist einfach bad practice.
Immerhin sind diese für alle lokalen Nutzer lesbar (z.B. mit ps, top oder direkt unter /proc). Klar ist es hier nur ganz kurz der Fall, aber sowas will man sich einfach nicht angewöhnen ;-)
(Mal abgesehen davon dass Passwörter so in deiner Shell-History landen...)
-> Einfach `passwd` nutzen wie weiter oben bereits angemerkt und man ist auf der sicheren Seite ;-)

Du kannst es auch direkt mit einem Kommando ändern:

echo "user:password" | chpassw

 

[horst_lafer]

Passwörter direkt als Teil von irgendwelchen Befehlen/Befehlsketten zu schreiben ist einfach bad practice.

Schon lange nicht mehr, das ist die alte Schule.
Bei automatisierten Skripten oder Dockerfiles, mit DEBIAN_FRONTEND=noninteractive ist es meist sogar die einzige Lösung.

Immerhin sind diese für alle lokalen Nutzer lesbar (z.B. mit ps, top oder direkt unter /proc). Klar ist es hier nur ganz kurz der Fall, aber sowas will man sich einfach nicht angewöhnen ;-)

Bash lässt schon seit Jahren keine stdin/stdout leaks von echo und printf mehr zu. ps und top können da überhaupt nichts von dem Passwort sehen.
Zusätzlich verwendet chpasswd eine Verschlüsselung, also der pipe gelangt garnicht erst an die Spitze in plain text.

Somit gibt es da keine Bedenken. Nur das Skript selbst sollte man dementsprechend mit chmod 500 behandeln.

 

[Zyxx]

Das ändert nur leider nichts daran das ein simples "Pfeiltaste hoch" in der History dir das im Klartext ausspuckt.
--> passwd regelt.

 

[preisi]

Das ändert nur leider nichts daran das ein simples "Pfeiltaste hoch" in der History dir das im Klartext ausspuckt.
--> passwd regelt.

Das ist tatsächlich noch ein viel besserer Grund. Da hab ich jetzt garnicht drangedacht, weil meine History einfach deaktiviert ist/nicht persistiert wird^^.

Schon lange nicht mehr, das ist die alte Schule.
Bei automatisierten Skripten oder Dockerfiles, mit DEBIAN_FRONTEND=noninteractive ist es meist sogar die einzige Lösung.

In solchen Fällen gibt es doch meines Wissens meist die Möglichkeit Passwörter per Umgebungsvariable einzubinden. Und die kann dann einfach in eine Datei mit restriktiven Berechtigungen gepackt werden und wird dann einfach gesourced.

Bash lässt schon seit Jahren keine stdin/stdout leaks von echo und printf mehr zu. ps und top können da überhaupt nichts von dem Passwort sehen.
Zusätzlich verwendet chpasswd eine Verschlüsselung, also der pipe gelangt garnicht erst an die Spitze in plain text.

Somit gibt es da keine Bedenken. Nur das Skript selbst sollte man dementsprechend mit chmod 500 behandeln.

Die Annahme "Nutzer verwendet Bash" find ich tatsächlich gefährlich. Es gibt ja immerhin eine Vielzahl von verschiedenen Shell-Implementierungen. Und nicht unbedingt bei allen ist echo/printf ein Shell-Builtin ;-)
Was das jetzt mit der "Verschlüsselung" von chpasswd zu tun hat erschließt sich mir aber nicht (zudem Hashing != Verschlüsselung).

 

[horst_lafer]

Das ändert nur leider nichts daran das ein simples "Pfeiltaste hoch" in der History dir das im Klartext ausspuckt.
--> passwd regelt.

Nur wenn das händisch in einen Terminal eingegeben wird und die History aktiviert ist, wäre es unter deinem Nutzer so sichtbar.
history -c könnte folgen, aber wenn du dabei bereits Bedenken hast dann gibt es wahrscheinlich größere Risikoquellen.

In solchen Fällen gibt es doch meines Wissens meist die Möglichkeit Passwörter per Umgebungsvariable einzubinden. Und die kann dann einfach in eine Datei mit restriktiven Berechtigungen gepackt werden und wird dann einfach gesourced.

Ob du bei einem Shell Skript das Passwort in einer Variable deklarierst oder direkt im Kommando Argument verwendest macht keinen Unterschied.
"Globale Variablen in Dateien packen" ergibt keinen Sinn, du meinst wahrscheinlich das Skript selbst, und das habe ich ja bereits erwähnt mit chmod 500 bzgl. Berechtigungen.

Die Annahme "Nutzer verwendet Bash" find ich tatsächlich gefährlich. Es gibt ja immerhin eine Vielzahl von verschiedenen Shell-Implementierungen. Und nicht unbedingt bei allen ist echo/printf ein Shell-Builtin ;-)

Die Std Leak Prevention gibt es ewig, in jeglicher Form.
Solange du kein System von < 2004 verwendest bist du auf der sicheren Seite, aber wie bereits gesagt gibt es dann andere Risikoquellen.

Was das jetzt mit der "Verschlüsselung" von chpasswd zu tun hat erschließt sich mir aber nicht (zudem Hashing != Verschlüsselung).

chpasswd verwendet default md5 Verschlüsselung, oder mit -m Argument.

 

[cann0nf0dder]

30 zeichen vs 6 ... passwd gewinnt mit großem vorsprung

 

[horst_lafer]

Du vergisst aber 1 Zeile vs 2 Zeilen und Automatisierbar vs Benötigt User Input.

 

[cann0nf0dder]

und eine umständliche syntax .. jedem selber überlassen aber ich für meinen teil bleibe bei passwd

 

[horst_lafer]

Bei passwd müsstest du das Passwort aber zweimal eingeben, also wären es im Endeffekt 3 Zeilen, mit insgesamt 22 Zeichen und tty input.

Da sieht der Einzeiler nicht schlecht aus, aber jeder hat seine Vorlieben. 🤝

Ich arbeite viel mit Docker und Live ISOs die unzählige Chroot bzw. Live Hook Skripte verwenden, da taucht das chpasswd und User Generierung oft auf.

Für normale Umgebungen ist passwd wahrscheinlich praktischer, ich hab halt schon den Einzeilerwahn.

 

[Zyxx]

Nur wenn das händisch in einen Terminal eingegeben wird und die History aktiviert ist, wäre es unter deinem Nutzer so sichtbar.
history -c könnte folgen, aber wenn du dabei bereits Bedenken hast dann gibt es wahrscheinlich größere Risikoquellen.

Deswegen passwd nutzen und nicht das Passwort im Klartext durch die Gegend pipen, das ist und bleibt bad practice sofern auch nur die Chance besteht das die Konsole von wem anders gesehen werden könnte.

 

[horst_lafer]

Ich habe meine Docker Brille abgenommen und bin bereit einzusehen, dass es auch andere Umgebungen bzw. Szenarien gibt, wo passwd wahrscheinlich praktischer ist.

Einigen wir uns auf "es kommt drauf an". 🤝