Linux-Benutzer Kennwort ändern? [Gelöst]

[jmar83]

Hallo zusammen

In einem C++-Quelltext liegt folgender Linux-Befehl inline vor:

Code: Alles auswählen

usermod -p $(openssl passwd '-C135Ny_') benutzer1

Nun gabs damit ein Problem da ein '-' am Anfang ist. Das Problem konnte ich reproduzieren als ich den Befehl in der Konsole eingegeben habe. Gleiche Meldung wie wenn das C++-Programm ausgeführt wird:

Code: Alles auswählen

passwd: Option unknown option -C135Ny_
passwd: Use -help for summary.
Aufruf: usermod [Optionen] BENUTZERZUGANG

Optionen:
  -c, --comment KOMMENTAR       Neuer KOMMENTAR im GECOS-Feld
  -d, --home HOME_DIR           Neues Home-Verzeichnis f�r den Benutzer-
                                zugang
  -e, --expiredate ABL_DATUM    Ablaufdatum auf ABL_DATUM setzen
  -f, --inactive INAKTIV        Passwort nach Ablauf von INAKTIV
                                deaktivieren
  -g, --gid GRUPPE              Erzwinge GRUPPE als neue prim�re Gruppe
  -G, --groups GRUPPEN          Neue Liste zus�tzlicher GRUPPEN
  -a, --append                  Benutzer zu zus�tzlichen Gruppen hinzuf�gen,
                                                                                                             die mit der Option -G angegeben werden, ohne
                                ihn dabei aus anderen Gruppen zu entfernen
  -h, --help                    Diese Hilfe anzeigen, sonst nichts
  -l, --login NEUER_NAME        Neuer Wert f�r den Namen des Benutzerzugangs
  -L, --lock                    Den Benutzerzugang sperren
  -m, --move-home               Den Inhalt des Home-Verzeichnisses an den
                                neuen Ort verschieben (nur mit -d benutzen)
  -o, --non-unique              Benutzung von doppelter (nicht einmaliger)
                                UID erlauben
  -p, --password PASSWORD       Ein verschl�sseltes Passwort als neues
                                Passwort verwenden
  -R, --root CHROOT_VERZ        Verzeichnis f�r chroot
  -s, --shell SHELL             Neue Login-Shell f�r den Benutzerzugang
  -u, --uid UID                 Neue UID des Benutzerzugangs
  -U, --unlock                  Den Benutzerzugang entsperren
  -v, --add-subuids FIRST-LAST  add range of subordinate uids
  -V, --del-subuids FIRST-LAST  remove range of subordinate uids
  -w, --add-subgids FIRST-LAST  add range of subordinate gids
  -W, --del-subgids FIRST-LAST  remove range of subordinate gids
  -Z, --selinux-user SEUSER     neue SELinux-Benutzer-Zuordnung f�r den
                                Benutzerzugang

Im ersten Moment finde ich wieder einmal gar nichts, wenn ich "passwd unknown option minus" (ohne Anführungszeichen!) bei Google eingebe...

Braucht es dazu einen Delimiter zum escapen oder sowas in der Art? Ich denke, dass es in diese Richtung geht...(?)

[rendegast]

Code: Alles auswählen

openssl passwd -- -pass123

[jmar83]

Vielen vielen Dank, werde es so schnell wie möglich anschauen!

[jmar83]

Wie kann ich beim vorgeschlagenen Befehl angeben, wer der Benutzer ist? Oder geht das vom aktuell eingeloggten Benutzer aus?

Folgendes habe ich bisher probiert:

usermod -p $(openssl passwd '\-Cl35Ny_') pi


...dann wird draus nicht das Kennwort "-Cl35Ny_", sondern "\-Cl35Ny". Also ist es scheinbar doch nicht möglich, das "-" mit "\" zu escapen...? Also ist leztendlich doch die einzige Möglichkeit, GAR KEIN "-" im Kennwort zu verwenden. (Kann ich mir nur schwer vorstellen, aber es gibt ja bekanntlich nix, was es nicht gibt...)

[jmar83]

Wie kann ich hier den Benutzer festlegen -> openssl passwd -- -pass123 ?

[DeletedUserReAsG]

Folgendes habe ich bisher probiert:

Und warum probierst du nicht genau das, was rendegast geschrieben hat? Das funktioniert nämlich.

Wie kann ich beim vorgeschlagenen Befehl angeben, wer der Benutzer ist?

Das ist die Option von usermod, so, wie’s oben steht.

[jmar83]

"Und warum probierst du nicht genau das, was rendegast geschrieben hat? Das funktioniert nämlich."

Weil ich zuerst wissen muss, wie und wo ich den Benutzer angeben muss...

Weder

root@xxx:~# openssl passwd pi -- -pass123
v1VB4qf5ri0Go
y5q8trA/x87WA
PnzZjrh5pZxxw

noch

root@xxx:~# openssl passwd -- -pass123 pi
VItisNbSDIWTg
WFCtU/zigMCHQ

ändern das Kennwort des Benutzers "pi" auf "-pass1234"....(?)

[jmar83]

"Weil ich zuerst wissen muss, wie und wo ich den Benutzer angeben muss..."

Sry. bin gerade ein wenig (na ja) im Stress... -> von wegen "Das ist die Option von usermod, so, wie’s oben steht."

[jmar83]

Danke!

Mit

usermod -p $(openssl passwd -- -C135Ny_) pi


scheint's zu klappen.

Frage: Ist dieser Befehlsaufbau auch erlaubt, wenn KEIN "-" am Anfang ist? Oder nur in diesem Fall? Vielen Dank für die Feedbacks.

[DeletedUserReAsG]

Ist dieser Befehlsaufbau auch erlaubt, wenn KEIN "-" am Anfang ist?

Ja. „--“ signalisiert bei vielen Programmen, dass keine weiteren Optionen mehr kommen, und alles, das danach kommt, als Daten zu interpretieren ist.

[jmar83]

Danke!!

[jmar83]

...allerdings scheint leider das hier nicht zu funktionieren:

Code: Alles auswählen

usermod -p $(openssl passwd -- ?.......) pi

jedoch (zumindest gemäss dem Arbeitskollegen) folgendes:

Code: Alles auswählen

usermod -p $(openssl passwd -- '?.......') pi

(Das Kennwort ist in diesem Fall ohne die Hochkommas...)


Frage: Kann ich die Hochkommas immer verwenden? Was ist, wenn ein Hochkomma in Kennwort enthalten ist? Muss ich es dann mit einen \-Delimiter escapen?

Mir ist dabei nicht ganz klar, welche Logik programmiert werden soll:

Beginnt Kennwort mit "a", also nix spezielles:

Code: Alles auswählen

usermod -p $(openssl passwd -- a.......) pi

(Würde wohl ausreichen, im momentan machen wir ja alles ohne Hochkomma. Abgesehen vom "?" am Anfang hat bis jetzt noch kein Zeichen ein Problem gemacht.

Das würde wohl auch gehen. (?)

Code: Alles auswählen

usermod -p $(openssl passwd -- 'a.......') pi

Beginnt Kennwort mit einem Hochkomma:

Code: Alles auswählen

usermod -p $(openssl passwd -- '\'.......') pi

Beginnt das Kennwort mit einem Backslash

Code: Alles auswählen

usermod -p $(openssl passwd -- '\\.......') pi

Beginnt das Kennwort mit einem Fragezeichen:

Code: Alles auswählen

usermod -p $(openssl passwd -- '?.......') pi

(Das, was gemäss des Arbeitskollegen funktioniert, was es vorher ohne Hochkommas nicht tat..)

[jmar83]

Das Sache müsste so flexibel sein (je nachdem muss dann evtl. der Linux-Befehlsstring in C++ halt anders zusammengesetzt werden, abhängig von den Zeichen im Kennwort) dass theoretisch jedes Zeichen drin sein dürfte. (Aktuell ist es aber nur eine Teilmenge aller verwendbaren Zeichen, wo leider so Sachen wie "?" und "-" drin sind...)

[DeletedUserReAsG]

OT, aber frage ich mich gerade: du gibt dir da furchtbar Mühe, einen Haufen Sonderzeichen reinzubekommen und damit das Passwort sicherer zu machen – aber dass bei dem Konstrukt das Passwort im Klartext in der Prozessliste auftaucht, macht doch alles wieder zunichte?

[jmar83]

"aber dass bei dem Konstrukt das Passwort im Klartext in der Prozessliste auftaucht, macht doch alles wieder zunichte?"

Ich denke das ist nicht wirklich ein Problem, denn während das Kennwort vergeben wird befindet sich das Gerät in einer "sicheren" Umgebung. Anschliessend wird es so oder so neu gestartet (zum anschliessenden Testen, ob alles richtig läuft) und danach heruntergefahren und dann ausgeliefert.

Ich meine dieses Konstrukt (mit "usermod" sowie "openssl" drin) wird doch verwendet damit man das Kennwort "in einem Zug", also ohne anschliessende Bestätigung (bei nicht root-Usern braucht's doch sogar noch zusätzlich das aktuelle Kennwort wenn man "passwd" alleine verwendet?) abändern kann. (Wie mir gesagt wurde...)

Verbesserungsvorschläge nehme ich natürlich jederzeit gerne entgegen.

[DeletedUserReAsG]

Hmm. Fehlen zuviele Infos. Wenn’s aber vor dem Ausliefern, nicht im Betrieb, gemacht wird, kann man die /etc/shadow auch manuell bearbeiten/generieren. Außerdem sehe ich nicht, warum das Auslieferungspasswort soviel Aufwand benötigen sollte – eine der ersten Sachen, die ein Empfänger von solchen Geräten machen sollte, wäre, das Passwort zu ändern.

[jmar83]

Geht um u.A. um primär- sowie sekundär-Betrieb, wenn das primäre Gerät ausfällt übernimmt das Sekundäre. Kennwort wird aus der MAC-Adresse generiert. Jedem Gerät wird die MAC des anderen Gerätes hinterlegt. Daraus wird dann das Kennwort errechnet, welches eine SSH-Verbindung aufbaut. U.A. Zwecks Synchronisation: Primäres Gerät zum Sekundären, wenn man nach einem Ausfall Daten auf dem Sekundären verändert, welches in dieser Situation die Rolle des Primären annimmt, und dann später wieder das Primäre zum Verbund hinzufügt, dann sollen die Daten wieder in die andere Richtung synrchonisiert werden...

Einfach mal den Algorithmus für die Kennwort-Generierung zu ändern ist zu heikel: "Einfache" Lösungen wie "-" oder "?" durch andere Zeichen zu ersetzen - angesichts der Tatsache dass gewisse Zeichen scheinbar nur am Anfang des Kennworts Probleme machen. (Siehe erster Problemfall, ohne die "--" davor mit dem "-") Das später zur Synchronisation aus der MAC generierte Kennwort würde dann nicht mehr zum ursprünglich mit "usermod", "password" sowie "openssl" gesezten Kennwort passen.

Die Systeme, welche bereits in Betrieb sind wären dann also nach einem Update nicht mehr in der Lage aufeinander zuzugreifen - es sei denn, man würde manuell eingreifen und überall beim entsprechenden User das Kennwort von Hand ändern...

[jmar83]

Und für den Kunden ist es gar nicht vorgesehen, das Kennwort zu ändern. Das würde gar nicht funktionieren: Passt das gesetzte Kennwort (Linux- sowie MySQL-Benutzer) nicht mehr zur MAC-Adresse auf dem Gerät selbst, so verweigert das Gerät den Dienst. Damit man nicht einfach die SD-Karte vom einen in das andere Gerät tauschen kann. Und, noch wichtiger, auch nicht die SD-Karte kopieren kann!

[DeletedUserReAsG]

Ich befürchte, an dieser Stelle muss ich dann passen. Hartcodierte Passwörter sind für erheblich viele Sicherheitsprobleme in der letzten Zeit verantwortlich, da will ich nix mit zu tun haben.

[mludwig]

Die Sicherheit des Systems (oder noch schlimmer: aller Systeme) basiert bei euch dann allein auf dem (geheimen?) Algorithmus, der aus der MAC-Adresse das Passwort generiert. Ist dieser einmal einem Angreifer bekannt, kann er die Passwörter aller Systeme berechnen. MAC-Adressen sind nicht wirklich geheime Informationen ... und der Algorithmus lässt sich vermutlich in eurem System aus dieser SD-Karte auslesen ...

Ich hoffe ich irre mich.

[jmar83]

Na ja, so gravierend ist es auch nicht:

- Wird in einem eigenen Subnetz betrieben (u.A. mit spez. VLAN- und Layer3-Switches sowie Access Points welche mehrere SSIDs haben und damit die versch. VLANs und Subnetze abbilden), wo nicht jeder den WLAN-Key kennt...

- Ist nicht dafür ausgelegt, mit offenem SSH-Port im Internet zu sein. Kein Problem jedoch mit VPN. (Web-GUI wäre möglich, aber da ist ein eigenes Kennwort zum Account. Wenn man Port 80 in eigenen Netz nicht dem Web aussetzen will, dann kann man das Gerät über eine öffentliche Webseite steuern)

- Ein grosser Teil des Codes (wichtige Teile der Logik) liegt in compilierter Form vor, und nur das (eher dumme) GUI in PHP, ein Bisschen MySQL, HTML, JavaScript, CSS etc..

[jmar83]

Ja, das man die Karte auf einem anderen Linux-System einlesen kann, ist fakt. Aber der Algorithmus ist definitiv nicht im Klartext...

Das Auslesen auf einem anderen System könnte man z.B. verhindern mit:

- Partitionen verschlüsseln mit Linux-Dateisystemverschlüsselung. (Aber ein System, wo der Schlüssel welcher entschlüsselt gleich auf demselben Datenträger ist und zwangsweise wohl in unverschlüsselten Bereich liegt -> SOWAS MISSTRAUE ICH PERSÖNLICH!!)

- HW-Verschlüsselung (Teuer, aufwändig und hat wohl auch das eine oder andere Problem..)

- Speicherkarte mit Sekundenkleber festkleben. (Na ja, die brachiale Tour halt..)

[jmar83]

"Ist nicht dafür ausgelegt, mit offenem SSH-Port im Internet zu sein. Kein Problem jedoch mit VPN. "

Jedoch nicht für den Kunden selbst damit er mit SSH selbst rumspielen kann. Wenn schon für den Support...

[mludwig]

Mag sein das dieses Verfahren bei Euch so ok ist, ich wollte aber darauf hinweisen dass dieses Design problematisch ist. Wenn die Systemsicherheit darauf vertraut, dass kein System jemals gehackt wird und euch dieser Algo nicht abhanden kommt (also auch kein System geklaut wird), dann ist das in meinen Augen schlechtes Design. In eurem Fall wird die Sicherheit dann vielleicht durch den Aufbau des übrigen Netzes erhalten, aber Defense in Depth ist eben besser, d. h. dem Angreifer immer mehrere Hürden in den Weg legen.

Wenn ich das so ansehe: ihr hinterlegt die MAC-Adresse des Slave-Systems auf dem Master, damit dieser das ssh-Passwort für eine Art Synchronisierung berechnen kann. Diese Berechnung und die Art wie die Verbindung dann aufgebaut wird wäre für den Angreifer dann hoch interessant, die MAC für das gegenüber hat er dann ja gleich mit.

Wieso hinterlegt ihr nicht den ssh-Key des anderen Systems, also key-Auth? und das Individuell für jedes System, so dass auch nur jeweils ein System oder ein Paar kompromitiert wäre. Wenn ein System abhanden kommt oder kompromitiert ist kann man auch einfach den Key tauschen. Das ist dann auch das normale Verfahren für ssh, tausendfach auf vielen Systemen erprobt, sogar direkt im Internet.

[jmar83]

Vielen Dank - natürlich kann dies kaum dementiert werden, das ist mir schon klar. Über ein Redesign müsste man bei Version 2.0 nachdenken, auf jeden Fall!

Habe es nun mit dem Mitarbeiter abgeklärt - Hochkommas werden im Kennwort nicht verwendet. Das macht nämlich aus Stress, denn man kann die Hochkommas nicht einfach mit einem \ escapen:

Code: Alles auswählen

usermod -p $(openssl passwd -- '\'.......') pi

...das hat nämlich zur Folge, dass der Befehl gar nicht zu Ende ausgeführt wird - man gelangt nicht wieder zu Konsole zurück, sondern ein '>' erscheint dann in der Unteren Zeile der Konsole, nach dem Eingeben dieses Befehls.

Da wie bereits gesagt keine Hochkommas verwendet werden, werden wir's wohl mal so versuchen alle Kennwörter in Hochkommas zu nehmen:

Code: Alles auswählen

usermod -p $(openssl passwd -- 'Kennwort_ohne_Hochkommas') pi

Hoffe mal das läuft so, aber das werden wir dann früher oder später sehen...