Fortführung Offtopic aus Neuer Serverstandort - coming soon!
wenn die Informationen einfach hier im Forum stehen und so auch die entsprechenden Beiträge mit passenden Suchwörtern einfach direkt über Suchmaschinen gefunden werden können.
In diesem Fall, ja und nein. Das Thema kann über Suchmaschinen gefunden werden, jedoch muss man zum Lesen im Forum angemeldet sein. Daher ist die genaue Information nur einem beschränkten Kreis zugänglich.
Die Kriese für die es Business relevant wäre wissen das sicherlich schon lange…
Knobelaufgabe zum Wochenende
Siegerehrung:
Die einköpfige Jury hat in einem einstimmigen Mehrheitsbeschluss die Antworten von KB19 auf den ersten Platz und von Olivetti auf den zweiten Platz gewählt.
Einige winzige Anmerkungen...
Vielen Dank für die hilfreichen Hinweise, das sollte sich jeder der das nicht kennt (und bisher nicht nutzte) näher ansehen 
Allgemeine Leseempfehlung, unabhängig von diesem Script
Danke auch für diesen konstruktiven HInweis! 
ich würde das script debuggen mit z.b.:
Bash #!/bin/bash set -vux …
Glückwunsch zur ersten konstruktiven Antwort auf die Knobelaufgabe und danke für den Hinweis auf die Debugmöglichkeit.
Hätte KB19 nicht so ausführlich geantwortet / nachgefasst, hätte er Dich auch nicht vom ersten Platz verdrängt... 
Änder die Shebang mal auf /bin/bash
Glückwunsch zum dritten Stockerlplatz und danke für den Hinweis auf Shebang. Das löste das gestellte Problem zwar nicht (Skript läuft ja prinzipiell), schärft aber die Aufmerksamkeit auch für solche Details.
Lösung:
Wie vermutlich die meisten Software- und Implementierungsfehler lag schlicht eine Fehlannahme vor.
Das Shellskript liegt im Ordner in dem sich auch die zu verarbeitenden Dateien befinden.
"Na dann wirkt es natürlich auch nur in dem Ordner, ist doch logisch..." 
Dank der Hinweise von Olivetti und KB19 war die Problemursache dann schnell ermittelt und ist anhand des Quellcodes auch nachvollziehbar:
Win98SE4ever:# printf "Start Debugging & Knobelaufgabenantwortenbewertung"
Start Debugging & Knobelaufgabenantwortenbewertung
Win98SE4ever:# sh daily-test.sh
cd $HOME
+ cd /home/user
datum_gestern=$(date -d "-1 day" "+%d-%m-%Y")
+ date -d -1 day +%d-%m-%Y
+ datum_gestern=28-06-2024
echo $datum_gestern
+ echo 28-06-2024
28-06-2024
...
Win98SE4ever:# pwd
/usr/test
Win98SE4ever:# printf "Du Bachel!"
Du Bachel!!!eins!111!!!
Win98SE4ever:# nano daily-test.sh
[Alt+r]: Search (to replace): $HOME
Replace with: #/usr/test #braucht's gar net, aber falls doch dann richtig
[Alt+r]: Search (to replace): set -vux
Replace with: #set -vux
[Strg+o]
[Enter]
[Strg+x]
Win98SE4ever:# sh daily-test.sh
Win98SE4ever:# wc -c Schnulliwutz_28-06-2024.tar
85746880 Schnulliwutz_28-06-2024.tar
Win98SE4ever:# exitSchön wegen so eines kleinen Fehlers ganz andere neue Dinge dazugelernt zu haben. 
Viele Grüße,
Win98SE4ever
P.s.:
Die Gänsefedern nehme ich gerne (für die nächste Winterdaunendecke) und den Teer nehme ich auch (und bring' ihn dem Gemeindebauhof zum Ausbessern der Schlaglöcher die es seit'm Frühjahr auf'm Radweg gibt). Die PS2-Tastatur des Skripterstellers kann man ihm nur schwer wegnehmen, denn die ist über einen PS2-DIN-Adapter formschlüssig am Pentium 133 Vobis-PC angesteckt (und vermutlich schon angerostet).
Über Google finde ich ganz oft Forenbeiträge von hier, die die eingebaute Suchfunktion nicht ausgibt.
Das stimmt, die Forensuche ist nicht die beste. Deswegen verwende ich oft site:
Bezüglich der Sufu weise ich gerne nochmal auf meinen Hinweis von damals hin:
Zur Knobelaufgabe.. ich hatte schonmal so einen Script Fail der besonderen Art..
Da habe ich einen uralten Ubuntu Server auf Debian umgezogen.. auf dem alten Server gab es ein Aufräumscript um Cache Verzeichnisse aufzuräumen. Dateien grösser 30 Tage wurde gelöscht.
Das Script hat über "find" ein "rm -R /*" ausgeführt. ich hatte es zwar sofort bemerkt, aber da war schon zuviel weg. Dank Backups war das zu retten.
Irgendwie waren da Gänsefüßchen benutzt worden die auf Debian/anderer Shell falsch interpretiert wurden.
Da habe ich einen uralten Ubuntu Server auf ein altes Debian umgezogen..
ich hab das mal korrigiert.
seit längerem ist ja default --preserve-root.
ich hab das mal korrigiert.
Stimmt, ich denke das war "Jessie".. das ist schon ein bisschen her.
Microsoft mal wieder. 
MTA helo: eur05-am6-obe.outbound.protection.outlook.com, MTA hostname: mail-am6eur05on2121.outbound.protection.outlook.com[40.107.22.121] (helo/hostname mismatch)Seit wann gibt es denn im SCP "Hostname"? Und wofür ist das gut? Dacht erst das sei der rDNS-Record, ist er aber anscheinend nicht.
Seit wann gibt es denn im SCP "Hostname"? Und wofür ist das gut? Dacht erst das sei der rDNS-Record, ist er aber anscheinend nicht.
Ist mir auch schon aufgefallen. Das ist der gleiche Hostname, den man während einer Image Installation setzen kann. Zumindest wurde dieser in meinem Fall automatisch ausgefüllt.
Sofern der nach ändern und speichern des Hostnamens an allen relevanten Stellen des OS dann ebenfalls dauerhaft geändert wird, ist das immerhin praktisch. Z.B. also auch in der /etc/hosts und anderen Dateien.
Hallo zusammen,
ein wichtiger Hinweis für alle Serverbetreiber:
In OpenSSH unter Linux wurde eine schwerwiegende Sicherheitslücke gefunden, die Remote Code Execution mit root-Rechten erlauben könnte (regreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems (CVE-2024-6387)).
Ihr findet hier weitere Informationen:
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
https://www.qualys.com/regresshion-cve-2024-6387/
https://www.openssh.com/releasenotes.html
Die Versionen 8.5p1 bis 9.7p1 (eingeschlossen) sind potenziell betroffen. Bei Debian wird diese bei Debian 12 (Bookworm) und höher genutzt:
https://security-tracker.debian.org/tracker/CVE-2024-6387
Für Debian 12 (Bookworm) steht bereits ein Update zur Verfügung.
Ein Workaround steht zur Verfügung, erlaubt aber Denial of Service-Attacken gegen den OpenSSH-Server:
"If sshd can’t be updated or recompiled, set LoginGraceTime to 0 in the config file. This exposes sshd to a denial of service by using up all MaxStartups connections, but it prevents the remote code execution risk."
(Quelle: https://blog.qualys.com/vulner…ability-in-openssh-server)
Serverbetreiber, die betroffene OpenSSH-Versionen auf einem Linux-System betreiben, sollten dringend patchen.
Danke, Lars. Nach apt update && apt upgrade -y bin ich allerdings immer noch auf Version 9.2p1, wie vorher. Wahrscheinlich brauchen die Paketquellen noch Zeit zum updaten...
Guck mal weiter: 9.2p1-2+deb12u3 ist die gefixte Version.
Danke, Lars. Nach apt update && apt upgrade -y bin ich allerdings immer noch auf Version 9.2p1, wie vorher. Wahrscheinlich brauchen die Paketquellen noch Zeit zum updaten...
Der Patch wird von Debian backported, die Hauptversion ändert sich nicht. Wenn du also laut dpkg -l openssh-server anstatt 9.2p1-2+deb12u2 nun 9.2p1-2+deb12u3 installiert hast, sollte das Problem behoben sein.
Wenn du also laut dpkg -l openssh-server anstatt 9.2p1-2+deb12u2 nun 9.2p1-2+deb12u3 installiert hast, sollte das Problem behoben sein.
Du hast Recht. Hab vielen Dank, also doch alles OK.
[netcup] Lars S. Vielen dank für die Info. Dickes Lob!
Informationen für Ubuntu: https://ubuntu.com/security/notices/USN-6859-1
(An dieser Stelle möchte ich erneut den Einsatz von port knocking empfehlen.)
An dieser Stelle möchte ich erneut den Einsatz von port knocking empfehlen
Ich habe das immer nicht gemacht, weil es noch eine Komponente im Stack ist, die unabdingbar funktionieren muss. Und weil ich sehr oft in Netzwerken unterwegs bin, die recht restriktiv konfiguriert sind, weswegen mein SSH-Port auch immer 22 ist.
Hast Du eine Empfehlung für eine Handy-App als Knocking-Client? Optimal wäre auch, wenn man durch das Knocking steuern könnte, ob der Port für alle Clients aufgemacht wird oder nur für die klopfende Absender-IP. Und IPv6 wäre Pflicht. Sigh, wenn man anfängt, mal zwei Minuten darüber nachzudenken …. Muss ich mich wohl tiefer mit beschäftigen.
