Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Alle weiteren Dienste, die nicht in die drei oberen Foren gehören.
breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von breakthewall » 09.01.2018 23:04:37

r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2018 15:29:30
Passwörter im Klartext in scripten anzugeben ist grundsätzlich eine schlechte Idee - benutze ssh-keys für die Authentifizierung.
Zu testzwecken kann ggf Debiansshpass verwendet werden.
Man kann Passwörter durchaus sicher in Shellscripten übergeben. Nur sollte man diese logischerweise nicht im Klartext in das Shellscript schreiben.

Beispiel:
viewtopic.php?f=37&t=165374&p=1133574&hilit=#p1133574

Somit könnte das so aussehen:

Code: Alles auswählen

#!/bin/bash

PASS="$(< /root/ssh-password)"
sshpass -f <(echo "$PASS") ssh user@host
Somit wäre das Passwort nur für Root lesbar, und ab Scriptstart nicht einfach so auszulesen.
Man müsste hier schon ab Scriptstart mit gdb oder strace loggen, und wenn das möglich ist für ein Fremdprogramm, dann stellt das die Systemsicherheit schon prinzipiell in Frage. Da braucht man dann auch nicht mehr mit Public-Keys arbeiten, die sind dann ebenfalls kompromittiert.
r4pt0r hat geschrieben: ↑ zum Beitrag ↑
09.01.2018 15:29:30
Und noch eine allgemeine Anmerkung: für scripte sollte man die bourne shell verwenden, nicht bash! Die default shell für cron auf sämtlichen linux- und UNIX-systemen ist sh und diese ist in POSIX standardisiert. bash ist oft sogar nichtmal zwischen verschiedenen Linux-varianten 100% kompatibel, portabilität ist somit nicht gegeben.
Nur weil in einer Crontab aus historischen Gründen /bin/sh steht, ist das nicht die Default-Shell, sondern nur jene Shell die historisch noch für Systemscripte genutzt wird. Auf so gut wie jeder modernen Linux-Distribution ist die GNU/Bash die Standard-Usershell. Ich hatte noch keine Distribution, in der irgendein Bashscript nicht anstandslos lief, ausser unter BSD, macOS und weiterem. Genau genommen nutzt einem diese vielfach angepriesene Kompatibilität garnichts, wenn man nur eine einheitliche Shell hat, aber die Userspace-Programme sich teils erheblich unterscheiden. Denn die GNU/Coreutils mal als Beispiel genommen, sind nicht automatisch mit BSD, macOS und Co. kompatibel, da hier jede Plattform ihre Eigenheiten hat. Von daher ist das eine unsägliche Arbeit, ein Shellscript kompatibel zu allen Plattformen zu machen, wo man besser Python nimmt oder direkt C, C++ und Vergleichbares. Und persönlich muss ich dazu sagen, dass der Posix-Standard verdammt alt ist, und heutige Belange garnicht auf dem Schirm hatte. Genau darum existieren doch erst Shells wie Zsh oder die Bash, um modernen Ansprüchen gerecht zu werden.

tobo
Beiträge: 535
Registriert: 10.12.2008 10:51:41

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von tobo » 09.01.2018 23:56:32

breakthewall hat geschrieben: ↑ zum Beitrag ↑
09.01.2018 23:04:37
Nur weil in einer Crontab aus historischen Gründen /bin/sh steht, ist das nicht die Default-Shell, sondern nur jene Shell die historisch noch für Systemscripte genutzt wird. Auf so gut wie jeder modernen Linux-Distribution ist die GNU/Bash die Standard-Usershell.
Nein, weder stimmt das für Debian noch allgemein. Das, was unter sh als Link eingetragen ist, das ist die default shell. Und das ist auch nicht historisch, sondern "schon immer so"!? Der Übergang von sh->bash zu sh->dash ist allerdings erst seit Squeeze. Vermutlich ist man der ganzen bashism leid geworden (siehe auch Slackware Init und Paketverwaltung)!?
man sh hat geschrieben:dash is the standard command interpreter for the system.
Nicht zu verwechseln mit dem, was man als interaktive Shell verwendet (bash, mksh, zsh, etc.).

breakthewall
Beiträge: 507
Registriert: 30.12.2016 23:48:51

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von breakthewall » 10.01.2018 02:54:12

tobo hat geschrieben: ↑ zum Beitrag ↑
09.01.2018 23:56:32
Nein, weder stimmt das für Debian noch allgemein. Das, was unter sh als Link eingetragen ist, das ist die default shell. Und das ist auch nicht historisch, sondern "schon immer so"!? Der Übergang von sh->bash zu sh->dash ist allerdings erst seit Squeeze. Vermutlich ist man der ganzen bashism leid geworden (siehe auch Slackware Init und Paketverwaltung)!?
man sh hat geschrieben:dash is the standard command interpreter for the system.
Nicht zu verwechseln mit dem, was man als interaktive Shell verwendet (bash, mksh, zsh, etc.).
Wenn ich deinen Post so lese, dann bestätigt sich damit eigentlich mein Post. Denn ich sagte, dass /bin/sh historisch (und somit noch immer/schon immer), für Systemscripte genutzt wird. Es ging auch nicht darum was unmittelbar mit /bin/sh verlinkt ist. Die Manpage sagt ebenfalls, diese Shell sei die Systemshell. Im Bezug auf die Bash sprach ich auch nur von einer Usershell, also jener Shell mit der ein Nutzer via Terminal unmittelbar Kontakt hat, und mit der regulär gearbeitet wird. Auch können beide Shells je nach Umstand interaktiv arbeiten. Missverständnis?

owl102
Beiträge: 2324
Registriert: 16.10.2010 13:05:57
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Timbuktu

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von owl102 » 10.01.2018 10:40:21

dmant hat geschrieben: ↑ zum Beitrag ↑
09.01.2018 20:02:40
Ich habe mir jetzt was kleines geschrieben.

https://nopaste.linux-dev.org/?1171834
Was mir neben den Sachen, die Meilo schon geschrieben hat, aufgefallen ist:

Alle ; in dem Script sind bis auf eine Ausnahme überflüssig, ich würde sie entfernen. (Die Ausnahme: "while true; do")

Außerdem verwendest du manchmal bei "test" die Syntax "[ x = y ]" und manchmal "[ x == y ]". Ich würde es einheitlich machen, in diesem Falle immer "[ x = y ]", denn das "==" kann POSIX nicht und in der bash würde man das am besten wieder anders schreiben, wenn man denn schon Bash-Features verwenden möchte, z.B. nicht

Code: Alles auswählen

if [ $SERVERSTATUS == 1 ] && [ $VPNSTATUS == 1 ]
sondern

Code: Alles auswählen

if (( SERVERSTATUS == 1 && VPNSTATUS == 1 ))
Alternativ könnte man solche Flags auch nicht auf 0 oder 1, sondern stattdessen auf "false" oder "true" setzen. Dann könnte man sie so abfragen:

Code: Alles auswählen

if $SERVERSTATUS && $VPNSTATUS
Zuletzt geändert von owl102 am 10.01.2018 18:45:43, insgesamt 1-mal geändert.
Fedora 28 Workstation -- openSUSE Leap 42 / Gnome -- Debian 9 (Qnap TS-109/119) -- OmniOS (HP N54L)

Benutzeravatar
Meillo
Moderator
Beiträge: 4962
Registriert: 21.06.2005 14:55:06
Wohnort: Balmora
Kontaktdaten:

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von Meillo » 10.01.2018 18:34:19

owl102 hat geschrieben: ↑ zum Beitrag ↑
10.01.2018 10:40:21
Alternativ könnte man solche Flags auch nicht auf 0 oder 1, sondern stattdessen auf "false" oder "true" setzen. Dann könnte man sie so abfragen:

Code: Alles auswählen

if $SERVERSTATUS && $VPNSTATUS
Abgefahrene Sache! Werd' ich mir merken. :THX:
Use ed(1) once in a while!

TomL
Beiträge: 3705
Registriert: 24.07.2014 10:56:59

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von TomL » 10.01.2018 19:05:49

Meillo hat geschrieben: ↑ zum Beitrag ↑
10.01.2018 18:34:19
owl102 hat geschrieben: ↑ zum Beitrag ↑
10.01.2018 10:40:21
Alternativ könnte man solche Flags auch nicht auf 0 oder 1, sondern stattdessen auf "false" oder "true" setzen. Dann könnte man sie so abfragen:

Code: Alles auswählen

if $SERVERSTATUS && $VPNSTATUS
Abgefahrene Sache! Werd' ich mir merken.
Ja, ist schön kurz... aber enthält leider auch Potential für Lese-Flüchtigkeitsfehler, was mich mal schier zur Verzweiflung gebracht hat. Und erst mit kdiff beim Vergleich mit der Vorversion bin ich dann drüber gestolpert. Ich hab zwar gelesen, was da stand, aber dummerweise verstanden, was ich eigentlich da erwartet habe... und hab dann über mich selber gedacht: :facepalm:

Code: Alles auswählen

if ! $SERVERSTATUS && $VPNSTATUS
Deswegen schreib ich es heute wieder in Langform.......
vg, Thomas

tobo
Beiträge: 535
Registriert: 10.12.2008 10:51:41

Re: Bash Scripting (was: Viele verschiedene Fragen (OpenVPN, tc, OpenSSL, Bash scripting))

Beitrag von tobo » 11.01.2018 00:19:01

owl102 hat geschrieben:sondern

Code: Alles auswählen

if (( SERVERSTATUS == 1 && VPNSTATUS == 1 ))
Wobei man mit dem arithmetischen (()) aber schon ein bisschen vorsichtig hantieren sollte, bezüglich der Unterschiede zum Exit-Status:

Code: Alles auswählen

$ true;if (($?));then echo TRUE;else echo FALSE;fi
FALSE
$ false;if (($?));then echo TRUE;else echo FALSE;fi
TRUE
TomL hat geschrieben:

Code: Alles auswählen

if ! $SERVERSTATUS && $VPNSTATUS
Also ich würde das NOT hier immer klammern, selbst wenn es nur für den ersten Operanden bestimmt ist. Mit Klammer ist es direkt lesbar/verständlich und ohne Klammer muss man mindestens mal den Gedankengang der Operatorpriorität mehr machen.
breakthewall hat geschrieben:Missverständnis?
Nein, ich habe mich nur vergleichsweise bescheuert ausgedrückt! Aber sowas artet dann eh in eine Grundsatzdiskussion - da habe ich jetzt wenig Nerv für...

Antworten