Category: Linux

Zu einer Debian 12 Installation im Rescue Modus mit ssh verbinden

Ich hab bei Ionos einen VPS mit einer größeren Festplatte ausstatten lassen, was leider nicht so reibungslos ging. Im Endeffekt hat der Server nicht mehr gebootet, aber ich konnte zumindest per Debian 12 ISO den Rescue Modus starten und mein “defektes” System mounten. Um darauf per SSH zugreifen zu können, damit ich z.b. die Daten nach extern sichern konnte, musste ich innerhalb des Rescue Systems (mit der Remote Shell im Browser) folgendes tun:

/etc/init.d/ssh start

falls das nicht geht, dann einfach so den SSH Server nachinstallieren:

apt-get update
apt-get install openssh-server

Anschließend konnte ich mich wieder per SSH verbinden, allerdings bekam ich keinerlei Output vom Remote Server, bis auf die Welcome Message. Um das zu beheben, muss man folgendes machen:

Prüfen ob pts richtig gemountet ist:

mount | grep pts

Wenn es hier keine Ausgabe gibt, dann einfach per

mount -t devpts devpts /dev/pts

korrigieren. Nach einer erneuten SSH Verbindung kam dann auch wieder der Output der Befehle in meinem SSH client an.

Docker meldet Chain DOCKER does not exist

Wenn docker beim Starten neuer Container die Meldung

Chain 'DOCKER' does not exist

ausgibt, dann bedeutet dies, dass für Docker keine IP-Talbes rules hinterlegt sind. Vermutlich kann das passieren, wenn man mit docker system prune aufräumt, so richtig sicher bin ich da aber auch nicht.

Falls der Fehler bei dir auch auftritt, kannst du ihn mit folgenden 3 Commands mittles root Permission auf dem entsprechenden Server lösen:


iptables -t nat -N DOCKER
iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER

Linux Server zeigt unterschiedliche Werte bei df und du

Wenn das Monitoring meldet, dass die Platte eines Servers voll läuft, ein

du -hs /*

aber deutlich weniger verwendeten Speicher anzeigt als man es per df sieht – dann gibts erstmal Verwunderung.

Eine google Recherche hat mich dann auf den Trichter gebracht, dass dies ein Zeichen von zwar gelöschten Dateien, aber noch offenen Dateihandles auf diesen liegen kann. Sprich, man hat zwar eine Datei gelöscht, aber ein Programm hat die Datei aktuell noch geöffnet. Dann ist zwar der Dateiname nicht mehr sichtbar, aber die Inhalte der Datei liegen noch immer auf der Festplatte und verbrauchen natürlich auch ensprechend Platz. In meinem Fall ist filebeat nicht mit einem Logrotate klar gekommen und hatte somit eine relativ große Log Dateien weiterhin geöffnet. Mit jedem Logrotate kam eine dazu…

Wie kann man das sichtbar machen? So:

lsof | grep "/var" | grep deleted

oder gleich mit

lsof | grep deleted

wobei man bei letzterem vielleicht ein paar Ergebnisse sieht, die berechtigt noch Handles offen halten.

Hier mal eine Beispielhafte Ausgabe:

Ganz links sieht man den Dienst bzw. Command, und in der ganz rechten Spalte die jeweilige Datei.

Normalerweise sollte es reichen, den entsprechenden Dienst einfach neu zu starten und das Problem ist erstmal behoben. Sollte der Fehler wieder auftreten, müsste dann evtl ein Update/Patch oder als letzte Möglichkeit ein kontrollierter regelmäßiger Neustart das Problem beheben.

raspberry pi 3 b+ will nicht booten

Die Geschwindigkeit meines Octopi Druckservers für meinen 3D Drucker hat mich in letzter Zeit etwas genervt, daher habe ich mir direkt einen ganz neuen Raspberry Pi 3 b+ bestellt. So wie immer dachte ich mir: Karte wechseln, booten, fertig. Aber nix da. Der neue Raspi bootet einfach nicht.

Ok, dann neues Image probiert, andere Karten, andere Kabel usw. Nichts half. Die rote LED blinkte immer nur in unregelmäßigen Abständen und auf meinem Monitor war nur das Bunte Viereck sowie das Blitzsymbol zu sehen, was eigentlich auf Stromprobleme hinweist. Was aber wiederum bei einem 2 oder auch 2.5 A Netzteil mit dicken Kabeln nicht sein kann.

Der Grund für das Problem war dann doch sehr einfach: man muss die SD Karte “richtig” formatieren ?…

Am besten lädt man sich dazu das offizielle Tool zum Formatieren von SD Karten runter (ja, das gibt es tatsächlich 🙂 ) und wählt dort bei der Formatierung “overwrite format” aus. Damit wird die komplette SD Karte einmal überschrieben. Anschließend spielt man mit einem Tool seiner Wahl ein AKTUELLES Raspbian oder Noobs Image auf, welches die Treiber für den neuen Raspberry enthält.

Im Falle von Octopi wie bei mir war es nötig, den aktuellen Nightly Build zu verwenden. Das letzte stable Release verwendet sogar noch die letzte Raspbian Version…

Beim Ausführungen von Java jnlp Anwendungen erscheint ein Access Denied Fehler

Beim Ausführen einer Java Anwendung mit einer jnlp Datei bekam ich komischerweise immer wieder Fehlermeldungen „java.io.FilePermission“ für die Datei „/usr/bin/xprop“. Die Datei war im System vorhanden und durfte auch von jedem ausgeführt werden, selbst mit Sudo kam der Fehler.

Die Lösung des Problems ist zwar relativ leicht, aber mal wieder sehr ärgerlich: es ist ein Fehler in der OpenJDK und in meinem Fall der icedtea-netx Implementierung. Und um diesen zu umgehen muss man leider die original Oracle JAVA JRE runterladen und installieren.

Wichtig hierbei: man muss wohl zwingend die tar.gz Variante und nicht die RPM Variante nehmen, da nur diese „javasw“ enthält.

Das Vorgehen für die Installation ist:

  • openjdk und co vom System schmeissen (es geht auch anders, aber man muss die Sache ja nicht unnötig verkomplizieren)
  • unter http://www.oracle.com/technetwork/java/javase/downloads/index.html den Download Button unter „JRE“ anklicken und auf der folgenden Seite die AGB akzeptieren und dann die entsprechende tar.gz für 64bit oder 32bit herunterladen
  • tar.gz entpacken und den Ordner nach /usr/java/[ORDNER_NAME] verschieben
  • anschließend (keine Ahnung ob das der richtige Weg ist, aber er funktioniert) unter /usr/bin per Link die java und javasw Binaries verlinken:
cd /usr/bin
ln -s /usr/java/[ORDNER_NAME]/bin/java
ln -s /usr/java/[ORDNER_NAME]/bin/javasw

Nun könnt ihr die jnlp Datei einfach per
javasw [DATEI].jnlp aufrufen.

WPA2 kann geknackt werden ?

Und zwar nicht eine Implementierung eines Herstellers, sondern der Standard selbst. Aber die gute Nachricht ist: es ist möglich, die Lücke zu schließen und dabei trotzdem kompatibel mit gepatchten als auch ungepatchten Systemen zu bleiben.

WPA2 führt beim Beitritt eines neuen Gerätes einen 4-Wege Handshake durch, bei dem der gemeinsame Encryption Key ausgehandelt wird. Bei der 3. Nachricht des 4-Wege Handshakes teilt der Access Point dem Client den Encryption Key mit und wartet auf die Bestätigung durch den Client. Da diese 3. Nachricht ja auch mal durch Paketverlust oder ähnliches verloren gehen kann, ist es möglich, diese erneut zu senden. Und genau das ist die Schwachstelle: der Angreifer kann dieses Paket mitlauschen und es dann immer und immer wieder an den Client schicken. Jedes mal, wenn dieser das Paket erhält, setzt er seine inkrementellen transmit/receive Packet Counter zurück und verhält sich so, als ob er gerade dem Netzwerk neu beigetreten ist. Durch diese ständigen Widerholungen kann der Angreifer das “Opfer” gezielt immer die gleichen Pakete verschicken lassen und diese dann relativ einfach knacken.

Besonders betroffen sind Linux und Android Systeme (besser gesagt wpa_supplicant in der Version 2.4), da ihnen durch einen Trick zusätzlich noch ein Schlüssel, der nur aus Nullen besteht, untergeschoben werden kann. Ab diesem Moment kann der komplette Netzwerkverkehr des entsprechenden Gerätes mitgelesen werden.

Die kompletten Details findet ihr hier: krackattacks.com

[Quicktip] Wie man go get und Atlasssian Stash bzw. Gitlab zusammen bringt

In meiner Tätigkeit als Jenkins Admin hat mir das Thema „go get“ und Stash viel Kopfzerbrechen bereitet. Letztendlich ist „go get“ eine Art Alias für git pull, jedoch wird da einige Magic angewendet. Im Normalfall – also mit github und auch plain git Repos funktioniert das ganze wunderbar, sobald man aber Software wie Gitlab oder Stash verwendet, wird es etwas problematisch. Zum einen ist das „.git“, welches sowohl Gitlab als auch Stash an jedes Repo hängen ein Problem, zum anderen aber auch SSH über alternative Ports.

Zum Problem der „.git“ Endung: hängt einfach ein weiteres „.git“ an euren „go get“ Command. Also:

go get git.mydomain.com/foo/bar.git.git

Etwas kniffliger ist die Verwendung eines alternativen Ports und ssh. Stash macht nämlich genau das – der ssh Port ist 7999 in der Default Config. Aber auch hierfür gibt es eine Lösung. Dazu müsst ihr die Datei „.gitconfig“ in eurem Home Folder editieren bzw. anlegen. Die Datei muss dann so aussehen:

[url "ssh://git@stash.yourdomain.com:7999/"]
insteadOf = https://stash.yourdomain.de/

Sobald ihr nun einen Checkout auf

https://stash.yourdomain.de/foo/bar.git

macht, biegt Git diesen Request auf

ssh://git@stash.yourdomain.com:7999/foo/bar.git

um. Somit könnt ihr auf andere Ports gehen, komplett auf andere Domains umschreiben usw.

[Quicktip] Wie installiere ich ein CA Zertifikat unter Debian Linux

Wenn ihr ein CA Zertifikat bzw. das zugehörige pem File auf eurem Debian Linux installieren möchtet, dann sind folgende Schritte nötig:

  • pem File unter /usr/share/ca-certificates ablegen
  • Datei /etc/ca-certificates.conf editieren und um den gerade hinzugefügten Dateinamen ergänzen. Falls ihr die Datei direkt in /usr/share/ca-certificates hinterlegt habt, dann reicht [Dateiname].pem, wenn ihr einen Unterordner erzeugt habt, dann ist der Eintrag [Unterordner]/[Dateiname].pem
  • als root bzw. per sudo “update-ca-certificates“ ausführen. Dort sollte euch gemeldet werden, dass mindestens ein Eintrag hinzugefügt wurde
  • fertig 😉

[Quicktip] Vagrant up kann die Netzwerkinterfaces nicht starten

Wenn ihr mit

vagrant up

eine virtuelle Maschine starten wollt und während des Hochfahrens die Fehlermeldung kommt, dass das Interface eth1 (oder eth2 usw.) nicht hochgefahren werden konnte, dann probiert folgendes:

  • Virtualbox öffnen
  • die laufende Vagrant Maschine im Virtualbox beenden und anschließend dort auch wieder starten, damit ihr diese direkt steuern könnt
  • anschließend mittels User „vagrant“ und Passwort „vagrant“ einloggen
  • mittels “sudo su“ zu root wechseln
  • “/etc/network/interfaces“ mit vi aufrufen und alle Zeilen löschen, die nichts mit eth0 zu tun haben. In der Regel sollte über diesen Zeilen „# VAGRANT START“ stehen
  • Anschließend noch den Ordner “/etc/udev/rules.d/70-persistent-net.rules“ mittels “rm -rf“ löschen
  • die Maschine herunterfahren und Virtualbox beenden
  • nun mittels „vagrant up“ die Maschine wieder starten, sie sollte nun erfolgreich booten
  • sollte die Provisionierung nicht starten, dann führt anschließend noch ein „vagrant provision“ durch