Bash Script Passwort Abfrage

[Anonymous User]

Abend,

ich lasse ein Bash Script in Debian 12 mit einer Systemd Service Unit starten, welche wiederum mit einer UDEV Regel gestartet wird.

USB rein -> UDEV startet service -> Service führt Bash Script aus.

Alles funktioniert soweit bis auf meine interaktive Passwortabfrage.

Das Script funktioniert, wenn ich es manuell ausführe.

read -s PASSWORD wird nicht beachtet, also habe ich es mit systemd-ask-password probiert, das wird immerhin ausgeführt und ich werde aufgefordert mein Passwort einzugeben. Nach Eingabe folgt: -bash: "passwort": Kommando nicht gefunden.

Weiß jemand bescheid?

 

[oicfar]

Weiß jemand bescheid?

Nein.

Das Script funktioniert, wenn ich es manuell ausführe.

Kein Wunder. Du bist in der gleichen Session. Somit klappt es nicht.

Keine Ahnung, ob das was du vorhast, geht.

Poste mal das Skript um erst zu verstehen, was Sache ist.

Ergänzung (21. Mai 2024)

Hier ist eine Erklärung wieso es mit systemd-ask-password nicht geht.

Ergänzung (21. Mai 2024)

Vielleicht https://unix.stackexchange.com/ques...way-to-pass-a-password-to-a-systemd-unit-file

 

[nutrix]

Was ist den bitte das login-gebende System? Das OS auf einem Gerät oder das OS auf dem USB-Stick?

 

[Marco01_809]

udev und systemd services laufen ja in ihren eigenen Scopes, nicht in der Session deines Nutzers. Wo soll die Passwortabfrage also hingehen?
Wenn du das Script manuell startest läuft es in deiner Session und STDIN kommt von deinem Terminal. Daher kannst du dein Passwort eingeben. Wenn du das Script via systemd startest dann läuft es in einem ganz anderen Scope. STDOUT/STDERR werden i.d.R. ins Journal weitergeleitet daher siehst du ggf. noch die Ausgabe, aber STDIN ist normalerweise einfach mit /dev/null verbunden und daher kann das Script niemals irgendeine Eingabe bekommen. Deine Eingabe geht einfach an die bash die in deinem Terminal läuft, welche einen Befehl erwartet. Daher kriegst du dein Passwort zurück mit dem Fehler Befehl nicht gefunden.

Hat das System eine graphische Oberfläche?

 

[Anonymous User]

@Marco01_809 Danke, das habe ich verstanden. Dann ist es wohl nicht möglich, dass mein Script automatisch ausgeführt wird, sobald ich den USB Stick einstecke. Theoretisch könnte ich das Script von nem Keyfile lesen lassen. Halt ohne Eingabe.

Hat das System eine graphische Oberfläche?

nein, Headless

Ergänzung (21. Mai 2024)

Was ist den bitte das login-gebende System? Das OS auf einem Gerät oder das OS auf dem USB-Stick?

auf dem Stick ist kein OS. Der wird in eine Debian 12 Maschine gesteckt. Ich kann nicht allzu viel vom Script preisgeben. Teilweise sensible Infos

 

[BFF]

Ausser Nutzer / Passwort im Klartext duerfte da nix Sensibles sein @Anonymous User

Die Infrastruktur bei Dir duersftest Du nicht abgebildet haben und interne IP aka eins.eins.elf sind eh verbrannt.
Wenn Dein Script dennoch so geheim ist, frag halt nicht wirklich nach Hilfe. 🤷‍♂️

 

[Marco01_809]

Schaue dir nochmal den letzten Link von @oicfar an. systemd-ask-password erwartet normalerweise dass das Passwort in STDIN eingegeben wird. Aber man kann --no-tty angeben, dann versucht es system-weit eine Eingabe von einem Agenten zu kriegen. Bei einem graphischen System könnte ein Agent z.B. so aussehen dass ein Popup aufgeht mit der Aufforderung ein Passwort einzugeben.
Da müsste man sich mal einlesen ob man es hinbekommt dass du auf irgendeinem Weg diese Aufforderungen bekommst. Einfacher ist es aber allemal wenn du das Script einfach in ~/.local/bin oder /usr/local/bin ablegst und manuell ausführst nachdem du den Stick eingesteckt hast.

Übrigens ist dein Passwort jetzt im Klartext in deiner ~/.bash_history gelandet. Dort werden alle Befehle die du ausführst aufgezeichnet, z.B. damit man mit Pfeil-nach-oben alte Befehle wiederholen und mit Strg+R durchsuchen kann. Die Datei würde ich zur Sicherheit mal shreddern, z.B. mit shred -uzn 1 ~/.bash_history.

 

[0x7c9aa894]

pinentry ?

Ist Teil des gunpg Projekts, und kann auch tty

 

[Anonymous User]

Ausser Nutzer / Passwort im Klartext duerfte da nix Sensibles sein @Anonymous User

Die Infrastruktur bei Dir duersftest Du nicht abgebildet haben und interne IP aka eins.eins.elf sind eh verbrannt.
Wenn Dein Script dennoch so geheim ist, frag ha

Ergänzung (21. Mai 2024)

Mäh... Es geht um die prinzipielle Funktion. Dazu muss man nicht das ganze Skript kennen. Meine Frage wurde schon sehr gut beantwortet.

Mein Vorhaben ist so, wie ich es mir vorgestellt habe, wahrscheinlich nicht möglich.

 

[R00kie]

Übrigens ist dein Passwort jetzt im Klartext in deiner ~/.bash_history gelandet. Dort werden alle Befehle die du ausführst aufgezeichnet, z.B. damit man mit Pfeil-nach-oben alte Befehle wiederholen und mit Strg+R durchsuchen kann. Die Datei würde ich zur Sicherheit mal shreddern, z.B. mit shred -uzn 1 ~/.bash_history.

Nicht, wenn das PW nicht wie ein Kommando bzw. als Parameter eingegeben wurde. Was aber laut erstem Post nicht der Fall ist.
Hier besteht kein Problem, das mit shred gelöst werden müsste.

~$ read -s pw
~$ echo "$pw"
test123
~$ history | tail -3
 2003  read -s pw
 2004  echo "$pw"
 2005  history | tail -3
~$

 

[Anonymous User]

Schaue dir nochmal den letzten Link von @oicfar an. systemd-ask-password erwartet normalerweise dass das Passwort in STDIN eingegeben wird. Aber man kann --no-tty angeben, dann versucht es system-weit eine Eingabe von einem Agenten zu kriegen. Bei einem graphischen System könnte ein Agent z.B. so aussehen dass ein Popup aufgeht mit der Aufforderung ein Passwort einzugeben.
Da müsste man sich mal einlesen ob man es hinbekommt dass du auf irgendeinem Weg diese Aufforderungen bekommst. Einfacher ist es aber allemal wenn du das Script einfach in ~/.local/bin oder /usr/local/bin ablegst und manuell ausführst nachdem du den Stick eingesteckt hast.

Übrigens ist dein Passwort jetzt im Klartext in deiner ~/.bash_history gelandet. Dort werden alle Befehle die du ausführst aufgezeichnet, z.B. damit man mit Pfeil-nach-oben alte Befehle wiederholen und mit Strg+R durchsuchen kann. Die Datei würde ich zur Sicherheit mal shreddern, z.B. mit shred -uzn 1 ~/.bash_history.

interessant. --no-tty funktioniert auch nicht.
Danke für den sehr wichtigen Hinweis! Die History habe ich deaktiviert.

Dann werde ich wohl ein Shortcut erstellen, wie ich trotzdem das Script bequem (fast automatisch) ausführen kann.

 

[Marco01_809]

Nicht, wenn das PW nicht wie ein Kommando bzw. als Parameter eingegeben wurde. Was aber laut erstem Post nicht der Fall ist.

Doch:

also habe ich es mit systemd-ask-password probiert, das wird immerhin ausgeführt und ich werde aufgefordert mein Passwort einzugeben. Nach Eingabe folgt: -bash: "passwort": Kommando nicht gefunden.

Da die Abfrage gar nicht funktionierte (systemd-ask-password STDIN nicht mit seiner TTY verbunden) ging sein eingegebenes Passwort an die bash, die selbiges dann als Befehl ausführen wollte.

 

[JumpingCat]

Das klingt verdächtig nach einem https://de.wikipedia.org/wiki/XY-Problem .

Wieso sollte udev ein Passwort abfragen?

 

[R00kie]

Mal eine ganz andere Idee: Du könntest dein Skript vielleicht mit z.B. netcat auf einem Port lauschen lassen und die ankommenden Informationen auf dem Port hashen und mit dem im Skript hinterlegten PW-Hash vergleichen.
Für die PW-Eingabe müsstest du allerdings ein separates Skript starten. Das könnte auf den entsprechenden Port prüfen und wenn dieser offen ist, eine verschlüsselte Verbindung herstellen und das von dir abgefragte PW senden.

https://askubuntu.com/questions/595849/is-it-possible-to-encrypt-the-communications-via-netcat

Das auf das PW-wartende Skript könnte vereinfacht so auf das PW warten und es mit Hashing weiterverarbeiten und abgleichen:

received_password=$(nc -l 9999 | gpg --decrypt --batch --passphrase "MySuperSecret123")

Und das Skript zur PW-Eingabe enthält bspw. folgendes:

read -s password
echo "$password" | gpg --symmetric --cipher-algo AES256 --batch --passphrase "MySuperSecret123" | nc -N localhost 9999

------------------------

@Marco01_809 Danke, hatte ich vergessen, dass beim Testen dieser Fehler unterlaufen ist. Hast absolut recht.

 

[nutrix]

auf dem Stick ist kein OS. Der wird in eine Debian 12 Maschine gesteckt. Ich kann nicht allzu viel vom Script preisgeben. Teilweise sensible Infos

Das heißt, die Scriptabfrage bezieht sich dann auf einen lokalen Benutzer dieser Maschine? Hast Du dann bedacht, daß Du dann alle Scripte auf dem Stick mit absolutem Pfad abfragen bzw. setzen mußt? Dein Script ist ja nicht im aktuellen Pfad des Benutzers mit ausführbar gekennzeichnet, oder?

Du mußt den Stick ja vorher irgendwie mounten, oder? Kannst Du das beeinflußen, wohin der Stick gemountet wird? Dann wird einfach, dann mußt Du nur einen entsprechend festen Pfad in dem Script setzen, so daß alle weiteren Subscripte unter diesem Pfad gefunden und gestartet werden.

 

[Anonymous User]

Muss nicht zwingend mit UDEV erfolgen. Ich wiederhole mich gerne noch einmal: Ich möchte, dass wenn ich einen USB Stick einstecke, oder meinetwegen einen Toaster, ein Script auf meinem Debian 12 PC ausgeführt wird. Dieses Script fragt nach einem Passwort und daraufhin passieren weitere Dinge. Auf dem USB Stick befinden sich Daten, die nur temporär im System gebraucht werden.

Udev hat sich gut angeboten. Wenn es andere Methoden gibt, nutze ich die gerne

Das heißt, die Scriptabfrage bezieht sich dann auf einen lokalen Benutzer dieser Maschine? Hast Du dann bedacht, daß Du dann alle Scripte auf dem Stick mit absolutem Pfad abfragen bzw. setzen mußt? Dein Script ist ja nicht im aktuellen Pfad des Benutzers mit ausführbar gekennzeichnet, oder?

Du mußt den Stick ja vorher irgendwie mounten, oder? Kannst Du das beeinflußen, wohin der Stick gemountet wird? Dann wird einfach, dann mußt Du nur einen entsprechend festen Pfad in dem Script setzen, so daß alle weiteren Subscripte unter diesem Pfad gefunden und gestartet werden.

Jap. Klar habe ich absolute Pfade genommen. Sorry für die Verwirrung. Sobald ich den Stick anstecke, wird ein Skript gestartet, welches LOKAL auf dem PC liegt. Dieses Skript mountet und entschlüsselt den Stick im System und macht dann weitere Dinge.

Ergänzung (22. Mai 2024)

@R00kie sehr interessanter Ansatz, merke ich mir. Allerdings für mich in diesem Fall zu umständlich. Wenn ich eh manuell ein Skript starten muss, dann kann ich auch gleich mein Hauptskript starten und das PW eintippen.

Mir kam auch noch ne Idee. Was haltet ihr davon:
iStorage dasAshur PRO2 4 GB AES Hardware Verschlüsselter USB Stick?

Soweit ich gelesen habe, wird der Stick erst vom BS erkannt, wenn dieser mit der Pin, Passphrase etc entschlüsselt wurde. Das wäre ideal, denn sobald entschlüsselt, würde die UDEV Regel greifen und mein Skript durchlaufen. So kann ich mir die Passwortabfrage im Skript sparen, die erst den Stick entschlüsselt. Wenn der Stick sich sowieso Hardwareseitig ver und entschlüsselt.

Die Frage ist, wie sicher ist so ein Stick? Ich bin kein Krypto Experte.
https://www.tech-review.de/test-istorage-datashur-pro2.html

 

[Evil E-Lex]

Mir kam auch noch ne Idee. Was haltet ihr davon:
iStorage dasAshur PRO2 4 GB AES Hardware Verschlüsselter USB Stick?

Nichts. Datenträger mit Hardwareverschlüsselung sind abzulehnen, weil die Implementierung meist löchrig wie ein Schweizer Käse ist.

 

[Anonymous User]

@Evil E-Lex Und wo steht das? Gibt es dazu Quellen? Würde mich freuen. Quelle "Trust me Bro" bringt mich nicht weiter.

Ergänzung: Gut, wir brauchen nicht über andere Implementierungen sprechen, da habe ich schon nachgelesen, dass die unsicher sind. Mich interessiert aber der Stick. Der soll angeblich deutlich besser sein...

Ergänzung (22. Mai 2024)

Ne, ganz sicher kaufe ich mir nicht dieses Teil! Soll ganz billig verarbeitet sein. Dem traue ich nicht. Dann setze ich auf bewährte Methoden. Mittlerweile konnte ich ein Shortcut programmieren. Ich stecke meinen SW verschlüsselten Stick ein, drücke 1 Taste und das Passwort wird abgefragt. Für mich eine brauchbare Lösung.

 

[nutrix]

Jap. Klar habe ich absolute Pfade genommen. Sorry für die Verwirrung. Sobald ich den Stick anstecke, wird ein Skript gestartet, welches LOKAL auf dem PC liegt. Dieses Skript mountet und entschlüsselt den Stick im System und macht dann weitere Dinge.

Ok, verstanden, danke. Dann wird etwas angesprochen, was im Script nicht im Pfad ist.
-bash: "passwort": Kommando nicht gefunden

Du hast ja geschrieben, daß die Sciptausführung lokal gestartet ja läuft. Daher vermute ich mal, daß Du im Script etwas neu startest oder einen Fork machst, so daß die bisherige Umgebung verloren geht. Hier müßtest Du mal PATH (per echo ...) prüfen, was hier ausgespuckt wird, wenn Du das Script per UDEV startest. Was hier auch hilft, wenn Du die Bash mit Optionen -vx versiehst, so daß Du hier debuggen kannst, was zur Scriptsausführung passiert. Man kann das dann auch in eine Datei umleiten, so daß Du am Ende etwas hast, was Du in Ruhe lesen kannst.

#!/bin/bash

set -vx
exec >dateiename 2>&1

Scriptzeilen...