|
Anzeige
|
Shell Skript User Input an Programm übergeben
Gast
#1856915
Hallo, ich möchte per Shell Script ein Passwort mit passwd setzen. Habe deshalb
verwendet, aber das funktioniert nicht. Ich vermute mal, die Eingabe wird irgednwie zu schnell gemacht und es wird angemeckert das die Passwörter nicht identisch seien?! Kann man zwischen den Eingaben eine kleine Pause einfügen? Oder wie könnte man das Problem sonst lösen? nein, da brauchst du keine Pause, das würde nichts ändern. Eigentlich sollte es so gehen. Ich habe es in der Kommandozeile probiert (als root):
Das hat geklappt, das PW wurde geändert. Als Skript funktioniert es auch:
Du bist dir bewusst, daß du mit passwd ohne Parameter das PW des gerade aktuellen Benutzers änderst? Ansonsten könntest du als root aufrufen: passwd benutzername Dann wird das PW dieses Benutzers geändert. > root@i4a:/etc # passwd <<EOF
----------------^
Du hast es als root probiert (Du hast Dich ja sicher extra für die
Antwort hier als root eingeloggt, denn dauernd als root eingeloggt zu
sein ist bekanntlich böse).
Als Nicht-root wird zunächst das derzeitige Passwort abgefragt. Zwei
Zeilen als Antwort reichen dann nicht (drei werden benötigt) und das
Skript muss deshalb in der normalen Anwendung scheitern. Denn wer
ändert schon das root-Passwort per Skript.
Hc Zimmerer schrieb: > Du hast es als root probiert (Du hast Dich ja sicher extra für die > Antwort hier als root eingeloggt, denn dauernd als root eingeloggt zu > sein ist bekanntlich böse). Für so etwas habe ich ein xterm mit su - als root laufen. Meiner Erinnerung nach liest passwd nicht von stdin, sondern direkt von /dev/tty. Kannst ja mal im Sourcecode nachgucken. und was ist /dev/tty ? Wenn ich jeweils "abc", "def" und ^D eingebe, bekomme ich:
Jörg Wunsch schrieb: > Meiner Erinnerung nach liest passwd nicht von stdin, sondern direkt > von /dev/tty. Kannst ja mal im Sourcecode nachgucken. Das hatte ich auch so in Erinnerung und habe das sicherheitshalber vor meinem Posting überprüft. Bei einem aktuellen Linux (Debian, Ubuntu) ist es nicht (mehr?) so: passwd <<EOF meinAktuelles dasNeue dasNeue EOF funktioniert. Klaus Wachtler schrieb: > und was ist /dev/tty ? Das "controlling terminal" des Prozesses. man 4 tty Habe mal versucht, das im FreeBSD-Sourcecode zu finden, ist mir aber nicht gelungen. Das geht mittlerweile über PAM derart verschlungene Pfade, dass ich da nicht durchgeblickt habe... Hmm, nö, ich hab's mal durch ktrace geschickt, das geht mittlerweile in der Tat von stdin. War wohl in einem früheren Leben ;), dass da direkt von /dev/tty gelesen wurde. Hc Zimmerer schrieb: > Das hatte ich auch so in Erinnerung Dann sind wir zumindest zwei. :-) Scheint durch PAM halt alles ganz anders geworden zu sein. Oha, eben auf diesem System (das dritte) nochmal probiert. Da kommt „passwd: Authentication token manipulation error“. Erklärung dafür habe ich keine. Ich nehme also sicherheitshalber alles zurück. Jörg Wunsch schrieb: > Klaus Wachtler schrieb: >> und was ist /dev/tty ? > > Das "controlling terminal" des Prozesses. Du kannst /dev/tty z.B. dazu verwenden, um bei einem Skript oder Programm, dessen stdin und/oder stdout, stderr umgeleitet ist, doch noch an die Tastatur und Schirm ranzukommen.
Gast
#1857161
hmm,
> Denn wer ändert schon das root-Passwort per Skript.
also nur als Hintergrund: das ist für ein Embedded System und zu Anfang
ist da Standardmässig kein root-PW gesetzt, was ich dann eben mit einem
Installskript nachholen will.
Das Skript wird als root ausgeführt, und so wie ich es gemacht habe
funktionierte es eben leider nicht.
Muss dann wohl nochmal rumprobieren...hatte schon öfters das Problem das
einige der Tools sich etwas anders verhalten haben, als z.b. bei einer
richtigen Debianinstallation...was weiss ich was für Sourcen die da
teilweise verwendet haben :(
aber vielleicht ändert es etwas wenn ich passwd explizit für root
aufrufe per Parameter...muss ich nochmal probieren
Gast
#1857164
das meldet mir passwd
Gast
#1857166
achso, rufe ich passwd ganz normal auf und mache selber die Eingabe, dann klappt das Passwort ändern problemlos funky schrieb: > also nur als Hintergrund: das ist für ein Embedded System und zu Anfang > ist da Standardmässig kein root-PW gesetzt, was ich dann eben mit einem > Installskript nachholen will. Dann wäre usermod -p möglicherweise das Tool der Wahl. Das ist für die Verwendung in solchen Skripten gedacht. Es benötigt allerdings das fertig verschlüsselte statt des Klartextpassworts. Entweder Du besorgst Dir dieses aus einer vorhandenen Installation oder bastelst was mit crypt(3) drumherum. Eine andere Möglichkeit, um Userinput vorzugaukeln, ist expect (Teil von Tcl). Hc Zimmerer schrieb: > Entweder Du besorgst > Dir dieses aus einer vorhandenen Installation oder bastelst was mit > crypt(3) drumherum. perl -e 'sub salt {@x=("a".."z","A".."Z","0".."9");\ return $x[int(rand(62))]}\ print crypt($ARGV[0], salt().salt()) . "\n"' hi "hi" ist dabei das Passwort.
Gast
#1857272
hmm...ich habe mir jetzt einfach mal den Hash aus der "/etc/passwd" kopiert und testweise mit "usermod" gesetzt...danach konnte ich mich auch noch einloggen und es scheint zu funktionieren mich wundert nur etwas, das "passwd" mir für das gleiche Passwort jedesmal einen anderen Hash produziert?! Dachte zu jedem Passwort gibt es nur einen einzigen Hash...raff gerade nicht wie das ganze dann überhaupt funktioniert mal sehen ob das ganze auch noch funktioniert, wenn ich den Hash auf einem anderen Rechner mit "usermod" setze Google mal nach „Salt“ im Zusammenhang mit passwd oder crypt (oder schau Dir einfach an, wie Jörgs Perlskript den Salt generiert und verwendet). salt ist mir schon ein Begriff...aber mir schwant, das dieser Salt dann Rechnerspezifisch ist...würde sonst ja nicht so viel Sinn machen. Und das würde bedeuten, das die Hashs nicht einfach austauschbar wären Der Salt ist nicht rechnerspezifisch. Er ist rein zufällig (na ja, so rein zufällig halt, wie der Rechner Zufall erzeugen kann). Er soll die Suppe einfach so versalzen, dass gleicher Ursprung nicht mehr erkennbar und zurück-berechenbar ist. Man muss den Ursprung schon kennen und genau gleich versalzen, um dasselbe Ergebnis zu erzielen. oh...ok ich seh gerade das ich mir das doch nochmal genauer durchlesen muss achso ok, hab jetzt gerade gelesen, das der Salt in der /etc/passwd selber mitgespeichert wird. Dann raff ich es doch :) Die wesentliche Idee hinter dem Salt ist, dass man nicht einfach durch das Ansehen der gecrypteten Passwörter bereits feststellen kann, dass zwei Nutzer das gleiche Passwort haben. Das rührt vor allem noch aus der Zeit, da jeder Nutzer die verschlüsselten Passwörter der anderen Nutzer beliebig einsehen konnte (wie es ja bei "plain NIS" immer noch der Fall ist).
Gast
#1857336
Hi, fuer sowas verwendet man normalerweiser einen expect script. Dieser wartet auf ein bestimmtes Token (wie "password:") und fuehrt dann das Passwort zu. Siehe man expect (falls schon installiert). Damit kann man auch schwierige Faelle, wie ein SSH-Passwort zufuehren. Bei aktuellen Linux-Installationen wird mit MD5 verschluesselt und nicht mehr mit DES. Also nichts mehr mit dem Basteln mit Salt.
Gast
#1857346
Dafür führen die Passwörter dann aber ein Schattendasein in der shadow-Datei, wohingegen in der /etc/passwd nichts mehr steht. olibert schrieb: > Bei aktuellen Linux-Installationen wird mit MD5 verschluesselt und nicht > mehr mit DES. Also nichts mehr mit dem Basteln mit Salt. Salt und MD5 sind keine Widersprüche. Das oben genannte crypt(3) in allen modernen Unixen (incl. Linux) vereint beides, und zwar nicht trotz, sondern mit und in Abhängigkeit vom Salt. Das Salt ist nach wie vor fester Bestandteil. Hc Zimmerer schrieb: > Das oben genannte crypt(3) in > allen modernen Unixen (incl. Linux) vereint beides Man muss dann nur im Salt bereits andeuten, dass man die MD5- Variante haben will: perl -e 'sub salt {@x=("a".."z","A".."Z","0".."9");\ return $x[int(rand(62))]}\ print crypt($ARGV[0], "\$1\$".salt().salt()) . "\n"' hi Ja, genau. Deshalb das „in Abhängigkeit vom Salt“. SHA kommt ja auch
noch hinzu (zumindest bei den meisten). Alle Methoden haben aber den
Salt gemeinsam, somit kein
> Also nichts mehr mit dem Basteln mit Salt.
sondern ein „Doch“. So war's gemeint.
Antwort schreiben |
Anzeige
|
