rsync ssh und Passwort Eingabe

[feldmaus]

Ok, aber wenn Jemand doch meinen Account crackt z.b. über java skripte über meinen Internet Browser und er weiß wie mein Server intern heißt, was kein Problem ist, dann kann er sich auch auf meinem Server einloggen über meinen Client. Daher halte ich es nicht für sinnvoll auf jedem Rechner und für jeden Benutzer solch ein verschlüsseltes public/private key paar zu hinterlegen.

Grüße Markus

Das ist Unsinn. Wenn jemand deiner Rechner knackt, hat er deswegen noch lange nicht die Informationen, die der authentication agent hat. Die hat er naemlich nur in den Prozessen, die *deine* aktuelle Session beinhaltet.

*Wenn* er da rankaeme, weil er zB einen Webserver Prozess uebernommen hat, dann hat er irgendwie Root-Rechte bekommen, und kann zB den gesamten Speicher dumpen. Dann hat er auch deine pexpect-loesung mit eingegebenem Passwort, bzw. er installiert ein root-kit und faengt einfach deine ganzen Eingaben ab beim naechsten rsync

Du meinst der Einbrecher wartet 2 Monate bis ich mein Update mache und schlägt dann zu. na hoffentlich hat der viel Kaffee zu Hause. Spaß muss sein.

Grüße Markus

[BlackJack]

@feldmaus: Du weisst aber schon das so ein Angreifer nicht den lieben langen Tag an seinem Rechner sitzt um live anzuschauen was Du tippst, sondern das einem Programm überlassen wird, was ihm die interessanten Daten sammelt und auswertet!?

[deets]

@feldmaus

Ob du deinen rsync alle 2 Monate machst oder nicht (oder was auch immer du alle zwei Monate so machst) hat doch damit nix zu tun.

Das pub/priv-Key Verfahren hat nur dann ein Sicherheitsproblem, wenn du die Keys nicht mit Passwoertern schuetzt. Womit sich oberflaechlich betrachtet kein Unterschied ergibt zwischen remote mit Passwort einloggen, und remote mit Key einloggen, aber jedesmal erstmal den Key entschluesseln zu muessen.

Und genau deswegen gibt es den SSH-Agenten, der dieses enstschluesseln *einmal* macht wenn du vor deinen Rechner sitzt, und dann machst du das nicht mehr. Ich verbinde mich am Tag dutzende male auf irgendwelche Server-Systeme, und per GIT + SSH nochmal ein paar dutzend mal mehr. Jedesmal ein Passwort einzutippen - da wuerde ich wahnsinnig werden. Wenn man natuerlich Arbeitsintervalle von 2 Monaten hat, ist das wahrscheinlich ein geringeres Problem.

Sobald du deinen Rechner wieder ausschaltest (bzw. dich abmeldest), ist der Key wieder so sicher wie irgendwas.

Ich schreibe das jetzt hier nochmal bewusst langsam, damit du das gruendlich lesen kannst: Wenn der key verschluesselt ist, kommt der hypothetische Angreifer nicht auf deinen Server, auch wenn er den privaten Key hat.

'Nuff said, es steht dir ja immer frei, auf deine eigenen Fuesse das Feuer zu eroeffenen

[feldmaus]

Ich glaube ich bin weiter gekommen. Allerdings fragt er mich immer noch nach meinem Passwort.

Code: Alles auswählen

                p=subprocess.Popen(['rsync',
                '--rsh=ssh -l '+BENUTZER,
                '-a',
                '--delete-after',
                '--stats',
                '--progress', 
                exclude_pre,
                exclude_post,
                source,
                target], stdin=subprocess.PIPE)
                p.communicate(benutzer_passwoerter[BENUTZER]+'\n')

Habe ich in meinem Code einen Fehler? Müsste eigentlich hinhauen.

[deets]

Ah, Klartextpasswoerter im Quelltext. Die Koenigsloesung. Ich rieche blutigen Fuss... aber sei's drum: es geht nicht, weil man dafuer (wie schon mehrfach hier + im von dir referenzierten Thread erwaehnt) fuer sowas pexpect notwendig ist. SSH verweigert die Annahme von Passwoertern ueber die Standardeingabe. Und *nein*, nur weil "sudo passwd" in dem anderen Thread das nicht macht, heisst das noch lange nix fuer SSH.

[feldmaus]

@deets
Das heißt subprocess.communicate versucht nicht den Kind-Prozess zu kontaktieren? Kann man den Kind-Prozess irgendwie raus bekommen und dann doch noch kontaktieren, oder wäre der Aufwand zu groß?

[deets]

*seufz*. Nein, das heisst es nicht. Subprocess communicate arbeitet ueber STDIN und STDOUT des Kind-Prozesses. Aber SSH arbeitet direkt mit dem *TERMINAL* in dem du dich befindest. Deshalb bekommst du die Passworteingabeaufforderung ueberhaupt zu sehen.

Und pexpect ist dafuer gemacht, genau so ein Terminal zu emulieren, und SSH "auszutricksen".

Hast du dir ueberhaupt mal die Muehe gemacht, das mal googeln, warum es das gibt?

http://lmgtfy.com/?q=python+pexpect


Das erste Resultat sagt alles.

Und zum wiederholten male (ich glaube, ich sehe schon ein bisschen aus wie eine Gebetsmuehle): wenn du SSH-key-authorization verwendest, dann hast du das Problem nicht. Falls das noch nicht klargeworden sein sollte. Ich hab' da mal ein kleines Programm geschrieben, das du bitte laufen laesst, bis es "klick" macht:

Code: Alles auswählen

while True:
    print "Wenn Public/Private-Key-Authorization benutzt wird, muss man keine Passwoerter eingeben"
    print "Wenn man das aus esoterischen Gruenden nicht moechte, sollte man auf den Rat weiser alter Maenner wie Leonidas & deets hoeren & pexpect verwenden"

Abbrechen mit Control-C wenn ein lautes "klick" im Kopf ertoent.

[feldmaus]

@deets
Bei subprocess kann man doch auch die Option shell=True nutzen, dann wäre das auch möglich?

Grüße Markus

[BlackJack]

@feldmaus: Nein. ``ssh`` schaut ob es die Eingaben von einem *Terminal* bekommt, also ob da ein *Benutzer* sitzt und die tatsächlich eintippt. Das tut es um zu verhindern dass Programme das Passwort "eingeben" können. Weil das eben gewisse Sicherheitsrisiken birgt. Also muss man versuchen ``ssh`` vorzuspielen, dass das Programm kein Programm sondern ein Benutzer an einem Terminal ist. Das macht `pexpect`.

[deets]

@deets
Bei subprocess kann man doch auch die Option shell=True nutzen, dann wäre das auch möglich?

Wieviele Varianten von "geht das?" - "nein, das geht nicht!" moechtest du noch durchexerzieren? Die Deutsche Sprache ist reich an Worten und Zeiten, da verballern wir locker noch ein paar Monate mit dem formulieren der immer selben Fragen und Anworten.

Also zur Abwechslung mal ein paar Fragen, die mich wirklich brennend interessieren:

Warum fragst du denn eigentlich hier, wenn du die Antwort nicht hoeren moechtest? Warum liest du nicht, was man dir zu lesen gibt?

[Leonidas]

Hallo feldmaus,

Ich habe eine Frage: was hast du denn gegen die "richtige" Lösung und zwar SSH Public-Keys? Ich sehe dass du versuchst mit Gewalt da irgendwas dummes durchzusetzen, aber welchen Sinn und Zweck verfolgt das, wenn man das "richtige" einfacher und sicherer hinbekommt?

[snafu]

@feldmaus: Shell != Terminal

Eine Shell bildet die Kommandozeile, die innerhalb deines Terminals läuft. Dem Programm, welches Benutzereingaben von Stdin haben möchte, ist es ziemlich egal, ob es über eine dazwischen geschaltete Shell oder direkt über den `exec*()`-Call aufgerufen wird. Es möchte sich nämlich mit einem *Terminal* unterhalten. Dieses Terminal kannst du entweder nach dem Aneignen des nötigen Hintergrundwissens mit einigen Zeilen an zusätzlichem Code selbst emulieren (Pythons Stdlib bietet alle nötigen Funktionen) oder du verwendest eben Pexpect.

[deets]

Dieses Terminal kannst du entweder nach dem Aneignen des nötigen Hintergrundwissens mit einigen Zeilen an zusätzlichem Code selbst emulieren (Pythons Stdlib bietet alle nötigen Funktionen) oder du verwendest eben Pexpect.

Und damit das nochmal ganz deutlich wird fuer unseren wissbegierigen Nager: diese wenigen Zeilen zusaetzlicher Code sind eben genau das, was in pexpect passiert. Und nicht irgendein magisches Argument an subprocess.

[feldmaus]

Hallo feldmaus,

Ich habe eine Frage: was hast du denn gegen die "richtige" Lösung und zwar SSH Public-Keys? Ich sehe dass du versuchst mit Gewalt da irgendwas dummes durchzusetzen, aber welchen Sinn und Zweck verfolgt das, wenn man das "richtige" einfacher und sicherer hinbekommt?

Ich bin der Auffassung, dass dies nicht immer sicherer ist. Ich weiß nicht was es alles für Möglichkeiten gibt so wie Alle hier und daher verfolge ich die Strategie, möglichst wenig Angriffsmöglichkeit zu bieten. Ein Angriffs-Beispiel mit Java nannte ich ja schon, auch Office Dokumente mit Makros wären eine Angriffsmöglichkeit. Wahrscheinlich gibt es noch mehr Möglichkeiten, mir reichen die Beiden jedenfalls schon.

Hier der funktionsfähige Code:

Code: Alles auswählen

            try:
                source=BENUTZER+katalog[eintrag]['Server'][0]+BENUTZER+katalog[eintrag]['Server'][1]+' '
                target=katalog[eintrag]['Client'][0]+BENUTZER+katalog[eintrag]['Client'][1]+' '
                (command_output,  exitstatus)=pexpect.run('rsync --rsh=\'ssh -l '+BENUTZER+'\' -a --delete-after --stats --progress '+
                                                  exclude_pre+exclude_post+source+target,
                                                  withexitstatus=1, events={'(?i)password':benutzer_passwoerter[BENUTZER]+'\n'})
                print command_output
            except Exception, e:
                print 'Fehler: '+str(e)

Grüße Markus

[BlackJack]

@feldmaus: Jetzt bastelst Du ja schon wieder eine Zeichenkette zusammen…

[feldmaus]

Beim Befehl pexpect wird 1 Zeichenkette erwartet.

[BlackJack]

@feldmaus: Nein, das ist nur eine Möglichkeit.

[deets]

@BlackJack

Seit der Fukushima-Katastrophe wird Ignoranz in feldmaus gemessen. Die uebliche Hintergrundignoranz liegt bei wenigen milli-feldmaus. Doch das Vollpfostometer zeigt in diesem Thread Werte von bis zu einem feldmaus! Das sind Bereiche, die bis dato nur am grossen Retardotron im Hirnforschungszentrum Juelich gemessen wurden. Vielleicht sollte man mal die Wissenschaftler hierauf aufmerksam machen...

[busfahrer]

Seit der Fukushima-Katastrophe wird Ignoranz in feldmaus gemessen. Die uebliche Hintergrundignoranz liegt bei wenigen milli-feldmaus. Doch das Vollpfostometer zeigt in diesem Thread Werte von bis zu einem feldmaus! Das sind Bereiche, die bis dato nur am grossen Retardotron im Hirnforschungszentrum Juelich gemessen wurden. Vielleicht sollte man mal die Wissenschaftler hierauf aufmerksam machen...

You made my Day

Gruß...busfahrer

[lunar]

@deets: Dieser Beitrag war jetzt nicht unbedingt nötig ...