Shell Skript User Input an Programm übergeben

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):

1

root@i4a:/etc # passwd <<EOF

2

> ganzneu

3

> ganzneu

4

> EOF

5

Geben Sie ein neues UNIX-Passwort ein: Geben Sie das neue UNIX-Passwort erneut ein: passwd: Passwort erfolgreich geändert

Das hat geklappt, das PW wurde geändert.

Als Skript funktioniert es auch:

1

#!/bin/bash

2

#

3

# Time-stamp: "15.09.10 11:12 testpw root?wachtler.de"

4

5

passwd <<EOF

6

neu

7

neu

8

EOF

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:

1

klaus@i4a:~ > cat

2

abc

3

abc

4

def

5

def

6

klaus@i4a:~ > cat </dev/tty

7

abc

8

abc

9

def

10

def

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.

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.

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

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.