SSH automatisch Kennwort mitliefern im Shell-Skript? [Gelöst]

[jmar83]

"Pseudo-terminal will not be allocated because stdin is not a terminal." für beides:

Code: Alles auswählen

/usr/bin/ssh $USERNAME@$HOSTNAME << EOF
EOF

Code: Alles auswählen

/usr/bin/ssh $USERNAME@$HOSTNAME << EOT
EOT

[jmar83]

Ebenfalls nix:

Code: Alles auswählen

ssh root:xxx@hostname

[Snoopy]

Hi,

ich würde nicht mit Klartext Passwörtern in Skripten etc. arbeiten, dazu gibt es SSH-Schlüssel die man zwischen den Geräten austauscht.
Danach ist das Eingeben von Passwörtern obsolet.

Eine Vorgehensweise ist hier beschrieben:
https://wiki.debianforum.de/Secure_Shel ... gen_sicher

[jmar83]

`sshpass` wäre eher suboptimal, da es "per default" nicht auf dem System vorhanden ist:
https://stackoverflow.com/questions/122 ... ith-script

[jmar83]

Danke für den Beitrag, ist mir während dem Schreiben dazwischen geraten!

Das mit den Schlüsseln kenne ich, aber aus bestimmten Gründen ist das aktuell (noch) kein Thema.

Und das Kennwort wird eh nicht im Skript hard-codiert (also als Variable festgelegt), sondern der Benutzer wird schon vorher dazu aufgefordert es einzugeben: Dies vor der lftp-Anweisung - diese ist zwar in der Lage, meine MariaDB-Client-Zertifikats-Dateien auf dem anderen Rechner (Master/Master-Cluster-Konstrukt mit gegenseitigen, durch SSL verschlüsselten Verbindungen) hochzuladen und dort "chmod 0400 DATEINAME" anzuwenden, aber `chown` unterstützt `lftp` als SFTP-Befehl nur auf lokale Dateien -> das ist eher ein schlechter Witz, wieso sollte ich `chown` innerhalb der `lftp`-Terminals verwenden wenn man, ganz normal, den `chmod`-Systembefehl verwenden kann, welcher eh auf jemdem Linux- und UNIX-System ist...?

-> https://github.com/lavv17/lftp/issues/563

Aus diesem Grund muss ich nach dem ganzen `lftp`-Kram noch ne zusätzliche SSH-Verbindung aufbauen, welche die gleiche Passwort-Variable verwenden wird die vorher `lftp`.

Wenn ich das gewusst hätte, dann hätte ich von Anfang an auf `lftp` verzichtet und native SSH/SCP-Technik verwendet. Aber leider habe ich keine hellseherischen Fähigkeiten, und kann auch nicht stundenlang irgendwelche Dokumentationen "durchackern" - na ja.

[eggy]

und kann auch nicht stundenlang irgendwelche Dokumentationen "durchackern" - na ja.

also lieber unsichere Server betreiben?

Der Betrieb von Servern setzt leider voraus, dass man sich in die Materie einarbeitet. Und das kostet nun mal Zeit. Find Dich damit ab.
Wenn Du das beruflich machst, sorg dafür, dass Du Zeit für Fortbildung bekommst, wenn nicht, wird das Kartenhaus auf lange oder kurze Sicht mit einem Riesenkrach über Dir zusammenfallen.
Wenn Du das aus Spaß an der Freude machst, dreh ne Stufe runter, die Kumpels können auch mal ne Woche auf den Team Server warten. Nimm das bitte nicht als Angriff, sondern als guten Ratschlag: nimm Dir die Zeit Dich in Ruhe mit dem Problem zu beschäftigen und auch die Hintergründe zu lernen. Macht dann auch gleich viel mehr Spaß.

Beschreib doch mal was Du machen willst, wahrscheinlich gibts nen besseren Weg, denn Passwörter im Klartext zu übertragen ist nur sehr sehr sehr (eigentlich nie) ne gute Idee. Falls es sowas wie "kopier die Datei auf den Server und führ dann das Script damit aus ist" ist: mit ssh ein Anderthalbzeiler.

[jmar83]

Wie recht du hast - volle Zustimmung!!

Privat mache ich das auch sehr gerne, und nehme mir auch lange Zeit dafür.

Aber im Job hab ich mittlerweile, abgesehen von LAMP-Servern, eine Art Aversion gegen das Thema entwickelt. (Gut, teilweise gibt's ab und zu mal Überschneidungen von Job-Linux- sowie privaten Linux-Themen - glücklicherweise! )

[uname]

@jmar83
Vielleicht kannst du mal erzählen, was du mit "lftp" bezweckst. Wenn du wirklich darüber chown usw. durchführen willst frage ich mich, warum du nicht einfach "ssh" verwendest. Das sollte sowohl interaktiv als auch über die Kommandozeile möglich sein. Vielleicht kannst du dein Ziel noch etwas genauer beschreiben und warum direkt ssh keine Option ist mal ganz unabhängig von SSH-Keys oder Passwort.

[jmar83]

Ja, wenn ich gewusst hätte dass das "doofe" lftp remote kein chown kann... ja, dann hätte ich von Anfang an SSH/SCP file transfer verwendet.

Der Autor von lftp hat mir die relativ lustige Antwort gegeben, dass man innerhalb der sich von lftp startenden Konsole dafür chmod auf das lokale Filesystem machen kann - wie süss!!

Da kann ich ja gleich das Standard-Linux-chmod verwenden.

Und nun ist halt das draus geworden, funktioniert und ich habe keine Lust weiter an dem Zeugs zu arbeiten, bin ja eigentlich Programmier (Und nebenbei, zumindest ab und zu, noch Delegierter des Teams (Teamleiter oder Lead Dev wäre übertrieben) und (Teil)Projektleiter - aber nur ab und zu, solange es dem Chef genehm ist was ich entscheide. "Junge für alles" halt, könnte man eher sagen... )

Code: Alles auswählen

lftp -p 22 -u $REMOTE_USERNAME,$REMOTE_PASSWORD sftp://$REMOTE_SERVER << EOF
    # Set connection parameters {
    set sftp:auto-confirm yes;
    set  ssl:verify-certificate no;
    set  net:timeout 3;
    set  ftp:passive-mode true;
    set  ftp:use-mode-z true;
    set  ftp:mode-z-level 9;
    set  ftp:use-allo true;
    # } Set connection parameters
    
    # Upload locally saved, self-generated certificates for other clients {
    mirror -R --allow-chown /etc/mysql/client_cert /etc/mysql;
    # } Upload locally saved, self-generated certificates for other clients
    
    # Remove locally saved, self-generated certificates for other clients {
    !rm -f /etc/mysql/client_cert/*;
    # } Remove locally saved, self-generated certificates for other clients
    
    # Set remote permissions {
    chmod 0400 /etc/mysql/client-cert.pem;
    chmod 0400 /etc/mysql/client-key.pem;
    chmod 0400 /etc/mysql/client-key-pkcs8.pem;
    chmod 0400 /etc/mysql/client-req.pem;
    # } Set remote permissions
    
    # Close SFTP connection after upload {
    quit;
    # } # Close SFTP connection after upload
EOF

# Set remote files owner with SSH, 'lftp' is not able to do a remote chown {
php /etc/mysql/changeperm.php -h $REMOTE_SERVER -u $REMOTE_USERNAME -p $REMOTE_PASSWORD
# } Set remote files owner with SSH, 'lftp' is not able to do a remote chown

PHP mit `phpseclib` (http://phpseclib.sourceforge.net/ ), welches in der Konsole, also nicht als Webapp, ausgeführt wird:

Code: Alles auswählen

<?php
  ini_set('display_errors', 1);
  ini_set('display_startup_errors', 1);
  error_reporting(E_ALL);

  $options = getopt("h:u:p:");

  if(!isset($options['h']) || !isset($options['u']) || !isset($options['p']))
  {
    echo "\r\n";
    echo "You need to set these parameters: " . "\r\n";
    echo "  Hostname: -h ... " . "\r\n";
    echo "  Username: -u ... " . "\r\n";
    echo "  Password: -p ... " . "\r\n";
    echo "\r\n\r\n";
    exit;
  }

  $options['h'] = trim($options['h']);
  $options['u'] = trim( $options['u']);
  $options['p'] = trim($options['p']);

  set_include_path('/etc/mysql/phpseclib1.0.18');
  require "Net/SSH2.php";

  $ssh = new Net_SSH2($options['h']);

  if (!$ssh->login($options['u'], $options['p'])) {
    exit("\r\n" . 'Login failed, wrong hostname and/or user credentials. Please try again.' . "\r\n\r\n");
  }

  $ssh->exec("chown mysql:mysql /etc/mysql/*.pem");
?>

...die Wahl fiel auf PHP weil das eh installiert ist. PERL würde weitere Packages für SSH- und Netzwerk-Sachen brauchen, aktuell habe ich auch keine Ahnung wie man die installiert. Und `sshpass` würde eine komplett neues Paket erfordern.

PHP kenne ich und die ganze Konstruktion besteht nun aus Skripts sowie dem zu inkludierenden Verzeichnis von `phpseclib`... so muss ich nur die paar Sachen auf ein System kopieren ohne irgendwelche zusätzlichen Pakete wie `sshpass` oder PERL-SSH-Erweiterungen zu installieren.

Aber die Sache mit den Schlüsseln werde ich beim nächsten Mal sicher anschauen, habe die Nase gestrichen voll von irgendwelchen Basteleien. (Welche bei mir aber praktisch immer funktionieren, auch langfristig)

[rodney]

Ja, wenn ich gewusst hätte dass das "doofe" lftp remote kein chown kann...

Dazu ein Zitat aus der lftp-manpage:

Code: Alles auswählen

Commands

[...]

	chmod mode files
	
	Change permission mask on remote files. The mode must be an octal number.

[jmar83]

Danke, aber der Entwickler sagt:

Code: Alles auswählen

[b]"Remote chown is not implemented, mirror can only chown local files."[/b]

-> https://github.com/lavv17/lftp/issues/563

Habe zuerst gedacht man müsse `mirror -R --allow-chown` machen oder das ganze evtl. zusätzlich noch mit `-s` kombinieren: https://lftp.yar.ru/lftp-man.html

Im letzten Post auf github spricht er dann plötzlich vom "fish protocol", keine Ahnung was das wieder lustiges ist. Na ja, bei Gelegenheit evtl. mal anschauen...

[jmar83]

Ach - es geht ja gar nicht um `chmod`, sondern `chown` !!! Sorry dass ich das zuerst falsch geschrieben habe!!!!

[MSfree]

Ach - es geht ja gar nicht um `chmod`, sondern `chown` !!! Sorry dass ich das zuerst falsch geschrieben habe!!!!

Na und. In dem von dir verlinkten Thread steht:

Remote chown is not implemented, mirror can only chown local files.

Es gehen also weder chown noch chmod.

[jmar83]

Doch, `chmod` scheint doch zu gehen, allerdings offenbar nicht mit `chmod 0400 /etc/mysql/*.pem;` oder `chmod 0400 /etc/mysql/*;` sondern nur einzeln:

Code: Alles auswählen

lftp -p 22 -u $REMOTE_USERNAME,$REMOTE_PASSWORD sftp://$REMOTE_SERVER << EOF
    # Set connection parameters {
    set sftp:auto-confirm yes;
    set  ssl:verify-certificate no;
    set  net:timeout 3;
    set  ftp:passive-mode true;
    set  ftp:use-mode-z true;
    set  ftp:mode-z-level 9;
    set  ftp:use-allo true;
    # } Set connection parameters
    
    # Upload locally saved, self-generated certificates for other clients {
    mirror -R --allow-chown /etc/mysql/client_cert /etc/mysql;
    # } Upload locally saved, self-generated certificates for other clients
    
    # Remove locally saved, self-generated certificates for other clients {
    !rm -f /etc/mysql/client_cert/*;
    # } Remove locally saved, self-generated certificates for other clients
    
    # Set remote permissions {
    chmod 0400 /etc/mysql/client-cert.pem;
    chmod 0400 /etc/mysql/client-key.pem;
    chmod 0400 /etc/mysql/client-key-pkcs8.pem;
    chmod 0400 /etc/mysql/client-req.pem;
    # } Set remote permissions
    
    # Close SFTP connection after upload {
    quit;
    # } # Close SFTP connection after upload
EOF

Dateien im Ziel:

https://user-images.githubusercontent.c ... 128629.png

(Bild zu gross, deshalb das img-Tag rausgenommen...)

- Das Verzeichnis ist nun allerdings aber nicht mehr `/etc/mysql/test` wie im Screenshot, sondern `/etc/mysql`... das test-Verzeichnis habe ich nur eingerichtet weil mein fälschlich verwendeter `mirror -R -e --allow-chown`-Befehl wegen dem `-e` (Flüchtigkeitsfehler) das ganze /etc/mysql-Verzeichnis geleert hat:
viewtopic.php?f=27&t=176089

- Des weiteren werden die Client-Zertis zuerst auch noch (vor dem Upload temporär unter `/etc/mysql/client_cert`) mit `chmod 0400 ... ` bearbeitet. Aber ich denke nicht dass sie deswegen auf dem Ziel-System auch 0400 haben! Sondern eher weil ich innerhalb der lptf-Konsole das `chmod` mache ("# Set remote permissions { ... # } Set remote permissions"). Und das ist NICHT lokal! Lokal ist das mit dem `!` vorne dran unter "# Remove locally saved, self-generated certificates for other clients { ... # } Set remote permissions" ... könnte ich natürlich auch ausserhalb der lftp-Konsole machen, wäre eleganter. Aber egal.

P.S.: `--allow-chown` ist aber wohl total überflüssig. Aber: Nützt's nix, schadet's nix!

...oder habe ich das Durcheinander. (?) Anyway, jedenfalls funktioniert's nun, im zusätzlichen PHP-Skript, welches mit "phpseclib" arbeitet, mache ich ja nur das unter lftp unmögliche `chown` auf der remote-Zielmaschine.