[BUG] SSH Authorized Keys CGI?

[cando]

Hallo,

Ich habe mal authorized keys nach wiki vom dropbear über das cgi eingerichtet. Dabei ist mir aufgefallen, dass wenn ich mehrere Schlüssel nacheinander eingebe (jeweils neue Zeile pro Schlüssel), diese nach dem Abschicken der Maske "verschwinden"

Weitere Nachforschungen haben ergeben, dass die Schlüssel trotzdem Funktionieren und nur in die obere Zeile angehängt werden (Scheinbar werden die Zeilenvorschübe entfernt)

Wäre es nicht geschickter, nach dem Entfernen der überflüssigen Vorschübe im Schlüssel den bekannten Schlüsselanfang durch newline + schlüsselanfang zu ersetzen, damit die Schlüssel wieder schön untereinander stehen und einzeln auch wieder änderbar / entfernbar werden?

Nur als Anregung...

Viele Grüße

cando

 

[RalfFriedl]

Hört sich sinnvoll an. Machst Du das?

 

[cando]

Ich finde die Stelle nicht, an der es hakt. Die Datei, die generiert wird im key-Verzeichnis, sieht in Ordnung aus, da ist ein Zeilenvorschub drin. Beim Auslesen auf dem UI ist der Vorschub weg und nur noch ein Leerzeichen drin.

 

[RalfFriedl]

Wie sieht es denn bei den anderen Dateien aus, die bearbeitet werden können? Da bleiben die Zeilenwechsel doch auch erhalten?

 

[cando]

Keine Ahnung, hab ich noch nie benutzt.

#!/bin/sh
out="# Benutzernamen welche mit SSH erreichbar sind:\n# Users which are potentially accessible via SSH:\n"
ids=$(authorized_keys_getuser)
for id in $ids
do
	user=$(echo $id | cut -d":" -f1)
	out="$out# $user\n"
done
out="$out#\n"
out="$out# Beispiel / Example:\n"
out="$out#---root\n#ssh-dss KEYSCHLUESSELKEYSCHLUESSEL\n"
out="$out#---user1\n#ssh-dss KEYSCHLUESSELKEYSCHLUESSEL\n#\n"
out="$out# Eine Zeile, die mit 3 Bindestrichen anfängt gefolgt von einem Benutzernamen\n"
out="$out# definiert, dass die folgenden Schlüssel für diesen Benutzer gelten.\n"
out="$out# If a line starts with three hyphens followed by a user name implies that\n"
out="$out# the following keys are assigned to that user.\n"
for id in $ids
do
	user=$(echo $id | cut -d":" -f1)
	dir=$(echo $id | cut -d":" -f2)/.ssh
	[ ! -f $dir/authorized_keys ] && continue
[B]	keys=$(cat $dir/authorized_keys)[/B]
	OIFS=$IFS
	IFS=""
	for key in $keys; do
[B]		out="$out---$user\n$key\n"[/B]
	done
	IFS=$OIFS
done
echo -e $out > /tmp/authorized_keys.tmp

Es soll scheinbar ja immer eine neue Zeile scheinbar für jeden Eintrag in der authorized_keys datei mit prolog

---user
key
---user
key
---user
key

geschrieben werden.

es kommt aber nur eine zeile und dann alle schlüssel in einer zeile hinterher, mit leerzeichen getrennt...

---user
key1 key2 key3...


wozu das ist


OIFS=$IFS
IFS=""
...
IFS=$OIFS


hab ich auch noch nicht herausgefunden

 

[olistudent]

Hi.
Bei mir mit IE8 sieht das wie im angehängten Bild aus.

MfG Oliver

edit: Wie siehts denn bei dir in der /tmp/authorized_keys.tmp aus? Sind da Zeilenumbrüche drin? Bei mir ja.

 

[cando]

@olistudent

Das Problem ist ein anderes.

wenn du zum root von mehreren PC aus einen authorized key erzeugst und nach wiki einspielst, dann werden die keys nacheinander mit einem whitespace dargestellt und nicht wie in der Datei mit Zeilenvorschub.

ich vermute mal, dass der Zeilenvorschub einfach irgendwo umgewandelt wird...

Man kann ja so was eingeben:

---root
ssh-rsa SCHLÜSSEL1 user@pc1
ssh-rsa SCHLÜSSEL2 user@pc2
...

und folgendes kommt dabei raus:

---root
ssh-rsa SCHLÜSSEL1 user@pc1 ssh-rsa SCHLÜSSEL2 user@pc2 ...

 

[hermann72pb]

@cando: Diese Geschichte mit OIFS-Variablen sieht für mich nach einem Überbleibsel aus. Der Verfasser wollte etwas mit der Variable machen, hat es aber nachher doch anders gelöst. Wer hat denn an der Baustelle gewerkelt? Kann er sich dazu äußern?
Zum Neuenzeilen-Vorschub und ähnlicher Problematik. Ich hatte es hier nicht genau verfolgt, weiß allerdings, dass man bei den Shell-Variablen mit den mehrzeiligen Zeichenfolgen tierisch aufpassen muss. Das sind die Gründe, warum ich sehr oft

variable2="$variable1"

anstatt

variable2=$variable1

in meinen Skripten schreibe. Manche würden es für überflüssig halten. Und in 98% der Fälle muss man diesen Bedenkenträger auch Recht geben. Dafür werden bei mir allerdings die seltenen 2% der Fälle abgedeckt, wo es wirklich eine Rolle spielt. Ich bin kein guter shell-coder und kann hier nicht genau definieren, wann "$variable", wann ${variable} und wann $(variable) besser zu schreiben wäre. Allerdings hat es meiner Meinung nach damit eindeutig zu tun.
Desweiteren sollte man nicht vergessen, dass wir nicht mit bash, sondern mit ksh (bitte korrigieren, wenn ich mich irre) zu tun haben. Da gibt es auch einige Abweichungen diesbezüglich. Die Steigerung in unserem Fall ist die Benutzung von busybox, die sich bei der shell-Behandlung auch manchmal etwas anders verhält.
Und überhaupt. Seid ihr euch sicher, dass \n in den Zeichenfolgen wirklich das bewirken, was man damit erreichen will? Geht es denn mit "doppelten Hochstrichen", oder sollte man dafür lieber 'einfache Hochstriche' nehmen? Da gibt es auch Unterschiede, die ich im Zusammenhang mit sed feststellen dürfte, die aber meiner Meinung nach auch in den Tiefen der shell und busybox ihre Ursprünge haben.

MfG

 

[cando]

Es tut ja der Funktion kein Abbruch, ich habe mich nur gewundert, wohin meine Schlüssel "verschwunden" sind...

Wer das auch immer gebaut har, wenn er mal Zeit und Lust hat - dann kann er es ja mal fixen. Sonst sollte man vielleicht im WiKi einen Hinweis schreiben (known issues), damit nicht der nächste anfängt zu suchen...

 

[RalfFriedl]

@cando: Diese Geschichte mit OIFS-Variablen sieht für mich nach einem Überbleibsel aus. Der Verfasser wollte etwas mit der Variable machen, hat es aber nachher doch anders gelöst.

OIFS hat keinen anderen Zweck, als den Wert von IFS zu sichern und nachher wieder herzustellen. Das heißt aber nicht, daß es überflüssig oder ein Überbleibsel wäre.

Zum Neuenzeilen-Vorschub und ähnlicher Problematik.

Es sieht mir nicht nach einem generellen Problem mit Zeilenvorschüben aus, weil im Beispiel von cando "---root" und "ssh-rsa ..." in verschiedenen Zeilen stehen.

Das sind die Gründe, warum ich sehr oft

variable2="$variable1"

anstatt

variable2=$variable1

in meinen Skripten schreibe. Manche würden es für überflüssig halten. Und in 98% der Fälle muss man diesen Bedenkenträger auch Recht geben. Dafür werden bei mir allerdings die seltenen 2% der Fälle abgedeckt, wo es wirklich eine Rolle spielt.

Die Zuweisung funktioniert in 100% der Fälle. Die Anführungszeichen schaden aber nicht.

Ich bin kein guter shell-coder und kann hier nicht genau definieren, wann "$variable", wann ${variable} und wann $(variable) besser zu schreiben wäre.

Das ist recht einfach:
"${variable}" kann man immer schreiben statt "$variable". Wenn nach dem letzten Buchstaben der Variable ein Zeichen kommt, das in Variablen-Namen vorkommen kann (Buchstabe, Zahl, Unterstrich), dann sind die geschweiften Klammern notwendig.
"$(variable)" ist etwas vollkommen anderes und wird normalerweise als $(kommando) geschrieben. Im Beispiel

ids=$(authorized_keys_getuser)

ist authorized_keys_getuser nicht eine Variable, sondern ein Kommando, in diesem Fall vermutlich eine Shell-Funktion, die irgendwo im Skript definiert wird.

Desweiteren sollte man nicht vergessen, dass wir nicht mit bash, sondern mit ksh (bitte korrigieren, wenn ich mich irre) zu tun haben.

Es ist ash, eine der Shells der Busybox.

Und überhaupt. Seid ihr euch sicher, dass \n in den Zeichenfolgen wirklich das bewirken, was man damit erreichen will? Geht es denn mit "doppelten Hochstrichen", oder sollte man dafür lieber 'einfache Hochstriche' nehmen?

Das \n funktioniert, und einfache Anführungszeichen würden es in diesem Fall nicht tun. Das hat nur mit der Shell und nicht mit Busybox zu tun. Die ash der Busybox versucht den Shell Standard vollständig zu implementieren.

---root
ssh-rsa SCHLÜSSEL1 user@pc1 ssh-rsa SCHLÜSSEL2 user@pc2 ...

Wie genau sieht die Datei authorized_keys aus? Die Ausgabe würde dafür sprechen, daß dort schon alles in einer Zeile steht.

 

[hermann72pb]

@RalfFriedl: Danke für die Aufklärung zu den Klammern! Es ist schon so, wie du sagst, dass die Klammer nur in bestimmten Fällen einen Sinn machen. Es gibt da allerdings einige Grenzfälle, wo man sowohl eine als auch andere Schreibweise verwenden kann. In dem konkreten Falle würde sie dann auch funktionieren. Ändert sich anschließend die Zeichenfolge, so kann es zu Fehlern kommen.
@cando: Um es genau rauszufinden, sollte man die Datei mit einem hex-Editor betrachten. Entweder jagst du sie über hexdump:

cat diese_config_datei | hexdump -C

oder eben mit dem MC-Editor (F3->F4)
Dann sieht man, was da für Zeilenumbrüche stehen und ob sie da stehen.

Da Oliver was von IE berichtet hat: Könnte es sein, dass es sich um ein simples html-Darstellungsproblem handelt?

MfG

 

[RalfFriedl]

Oliver hat nur einen Schlüssel pro User.
Bei cando sind auch Zeilenumbrüche vorhanden, nur nicht zwischen den Schlüsseln.

 

[MaxMuster]

Cando war schon auf der richtigen Spur, denke ich. Im "for key in $keys; do" wird das Erkennen von "Einzelteilen" für das for ja durch IFS bestimmt. Mit IFS="" wird eigentlich "nichts mehr" als Trennzeichen erkannt, eigentlich bräuchte man dann ja keine Schleife mehr?!?
Zumindest in der von Cando genannten Situation sollte es so gehen...

for id in $ids
do
        user=$(echo $id | cut -d":" -f1)
        dir=$(echo $id | cut -d":" -f2)/.ssh
        [ ! -f $dir/authorized_keys ] && continue
        keys=$(cat $dir/authorized_keys | sed 's/$/\\n/' | tr -d '\n' )
        out="$out---$user\n$keys\n"
done

Jörg

 

[elmicha]

Es liegt an der letzten Zeile in authorized_keys_gentmp:

echo -e $out > /tmp/authorized_keys.tmp

Ohne Anführungszeichen wird $out von der Shell in Wörter aufgeteilt (egal, ob da vorher Leerzeichen, Tabs oder Zeilenumbrüche zwischen den Wörtern standen) und dann mit Leerzeichen getrennt ausgegeben.

echo -e "$out" > /tmp/authorized_keys.tmp

und es klappt.

 

[hermann72pb]

Genau das meinte ich ganz oben. Hättet ihr einfach auf mich gehört:

/var/mod/root # aaa="zeile1\nzeile2\nzeile3"
/var/mod/root # echo $aaa
zeile1\nzeile2\nzeile3
/var/mod/root # echo "$aaa"
zeile1\nzeile2\nzeile3
/var/mod/root # echo "Zeile1" >> /tmp/test
/var/mod/root # echo "Zeile2" >> /tmp/test
/var/mod/root # echo "Zeile3" >> /tmp/test
/var/mod/root # aaa=$(cat /tmp/test)
/var/mod/root # echo $aaa
Zeile1 Zeile2 Zeile3
/var/mod/root # echo "$aaa"
Zeile1
Zeile2
Zeile3
/var/mod/root # echo $aaa | hexdump -C
00000000  5a 65 69 6c 65 31 20 5a  65 69 6c 65 32 20 5a 65  |Zeile1 Zeile2 Ze|
00000010  69 6c 65 33 0a                                    |ile3.|
00000015

Es gibt da noch weitere Fälle, bei denen man noch variable=$(commandos) ebenfalls in die doppelten Hochstriche einschließen muss. Beim echo wird komischerweise kein richtiger Zeilenumbruch produziert, sondern 0x5a. Warum auch immer.

MfG

 

[elmicha]

0x5a ist das "Z" von "Zeile1/2/3" - das Leerzeichen 0x20 steht direkt davor.

 

[MaxMuster]

Das Problem ist hier, dass das gesamte Skript davon ausgeht, dass in der selbst erzeugten Variable "out" keine echten Zeilenumbrüche (0x0a) sind, sondern dass die als "\n" codiert im String sind und bei der Ausgabe mit "echo -e" erst erzeugt werden.
Deshalb gibt es auch die beiden oben genannten Möglichkeiten, entweder in den Keys die Zeilenumbrüche auch so zu codieren, oder aber $out mit Anführungszeichen "vor der Shell zu schützen".

Beim echo wird komischerweise kein richtiger Zeilenumbruch produziert, sondern 0x5a. Warum auch immer.

Hast du doch direkt davor geschrieben: Die Anführungszeichen ;-) (und 0x5a ist das "Z" bei mir 0x7a das kleine z)

/var/tmp # aaa="zeile1\nzeile2\nzeile3"
/var/tmp # bbb=$(echo -e $aaa)
/var/tmp # echo $aaa
zeile1\nzeile2\nzeile3
/var/tmp # echo $bbb
zeile1 zeile2 zeile3
/var/tmp # echo "$bbb"
zeile1
zeile2
zeile3
/var/tmp # echo $bbb | hexdump -C
00000000  7a 65 69 6c 65 31 20 7a  65 69 6c 65 32 20 7a 65  |zeile1 zeile2 ze|
00000010  69 6c 65 33 0a                                    |ile3.|
00000015
/var/tmp # echo "$bbb" | hexdump -C
00000000  7a 65 69 6c 65 31 0a 7a  65 69 6c 65 32 0a 7a 65  |zeile1.zeile2.ze|
00000010  69 6c 65 33 0a                                    |ile3.|
00000015
/var/tmp #

 

[hermann72pb]

Du hast Recht:

/var/mod/root # echo "$aaa" | hexdump -C
00000000  5a 65 69 6c 65 31 0a 5a  65 69 6c 65 32 0a 5a 65  |Zeile1.Zeile2.Ze|
00000010  69 6c 65 33 0a                                    |ile3.|
00000015

Das heißt echo bastelt da Leerzeichen anstatt Zeilenumbrüche, wenn man die Variable nicht mit doppelten Hochkommas umschließt?
Ich hatte -wie gesagt- irgendwo Fälle gehabt, wo dann nur die erste Zeile angezeigt wurde. Weitere Zeilen dann abgeschnitten. Leider kann ich es hier nicht reproduzieren / provozieren. Das wäre eigentlich das, was ich erwarten würde. Leerzeichen anstatt Umbrüche ist irgendwie ungewöhnlich.

MfG

 

[MaxMuster]

Nein, die Shell wertet die Variable dann so aus. Das "echo" gibt es nur wieder...

 

[cando]

Also in der authorized_keys Datei steht ein sauberer einzelner Linux Zeilenvorschub (0x0a) zwischen den Schlüsseln....