Fryboyter

Arch Linux ARM - Keine Verbindung per SSH mehr möglich

In meinem privaten LAN ist ein Raspberry Pi 4 vorhanden der neben ein paar anderen Dingen eine Kombination von PiHole und unbound zur Verfügung stellt. Vor ein paar Tagen hat die Namensauflösung auf den Rechnern im LAN nicht mehr funktioniert.

Als ich mit SSH mit dem Raspberry Pi verbinden wollte, konnte keine Verbindung aufgebaut werden. Sehr seltsam…

Meine erste Vermutung war, dass die Speicherkarte defekt ist, da ich diese schon einige Jahre nutze und auch schon ein viele Schreibvorgänge stattgefunden haben. Also habe ich die Karte aus dem Raspberry Pi entfernt und mittels eines Kartenlesers an mein Notebook angeschlossen. Sofort wurden die beiden Partitionen auf der Speicherkarte erkannt, ich konnte sie mounten und auf die Dateien zugreifen. Also ist es scheinbar doch nicht die Speicherkarte.

Trotzdem habe ich erst mal ein Image der Karte erstellt und dieses dann mittels PiShrink auf eine annehmbare Größe verkleinert.

Vielleicht steht ja in den Log-Dateien etwas, dass auf das Problem hinweist. Da am Raspberry Pi weder ein Monitor noch eine Tastatur angeschlossen ist, habe ich die größere der beiden Partitionen gemountet. Nehmen wir an im Home-Verzeichnis des Notebooks im Verzeichnis rasp. Dann habe ich mittels journalctl -D ~/rasp/var/log/journal -r auf die Log-Dateien auf der Speicherkarte zugegriffen. Schon nach wenigen Zeilen habe ich die erste und einzige Fehlermeldung gefunden.

alarmpi systemd[1]: Failed to start Wait for Network to be Configured.
alarmpi systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
alarmpi systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
alarmpi systemd-networkd-wait-online[322]: Timeout occurred while waiting for network connectivity.

Der Raspberry Pi bootet also, kann aber keine Netzwerkverbindung aufbauen. Aber warum? Die Konfigurationen habe ich seit mindestens einem Jahr nicht geändert.

Trotzdem habe ich mir die Konfigurationsdatei eth0.network unter ~/rasp/etc/systemd/network/ angesehen.

Sieht gut aus.

[Match]
Name=eth0
...

Wobei… Moment! Eth0 bei einer Distribution die systemd und somit Predictable Network Interface Names nutzt? Könnte das die Ursache sein?

Einen Versuch ist es wert. Also habe ich Name=eth0 in Name=en* geändert, da der Netzwerkanschluss per Kabel immer eine Bezeichnung zugeteilt bekommt die mit en beginnt. Welche genau, kann ich nicht sagen, da ich ja keinen Zugriff im laufenden Betrieb habe.

Und siehe da, der Raspberry Pi bootet und eine Verbindung per SSH ist wieder möglich. Mittels ip addr habe ich mir dann die Netzwerkverbindungen des Raspberry Pi anzeigen lassen und festgestellt, dass der Netzwerkanschluss per Kabel die Bezeichnung end0 hat. Also ich ich abschließend Name=en* noch in Name=end0 geändert. Wobei das ist in dem Fall nicht nötig ist, da nicht zwei unterschiedliche Netzwerkanschlüsse mit Kabel vorhanden sind. Aber sicher ist sicher.

Aber warum ist das erst jetzt passiert? Predictable Network Interface Names gibt es unter systemd schon ewig und sind in der Standardkonfiguration aktiv. Nachdem ich im offiziellen Forum von Arch Linux ARM gesucht habe, habe ich mehrere Fälle mit dem gleichen Problem gefunden. Z. B. https://archlinuxarm.org/forum/viewtopic.php?f=15&t=16245. Zumindest bin ich nicht alleine. Ich vermute, dass durch ein Update Predictable Network Interface Names aktiviert wurden und es deshalb zu Problemen gekommen ist, weil meine Installation schon sehr alt ist. Aber das ist eine Vermutung.

OSBN

SSH-Verbindungen leicht gemacht

Ich nutze regelmäßig SSH-Verbindungen zu diversen Rechnern. Im LAN z. B. zu meinem Receiver oder zu meinem Quake-3-Arena-Server. Da letzterer im Internet erreichbar ist, läuft SSH nicht auf dem Standardport, sondern auf einen anderen um Scriptkiddies zu blocken und somit die Logdateien sauber zu halten. Somit muss ich jedes Mal, wenn ich mich mit dem Rechner verbinden will ssh $Benutzer@$IP -p $Portnummer -i ~/.ssh/quake eingeben. Oder den Befehl aus der Historie von ZSH herausfischen. Das muss doch auch besser funktionieren, oder? Ja tut es.

Hierzu legt man, falls nicht schon vorhanden, als Erstes die Datei ~/.ssh/config auf dem Rechner mit dem man sich mit dem Server verbinden will an und erstellt in dieser Datei folgenden Eintrag.

Host quake
Hostname 192.168.1.220
Port 1234
User quake
IdentityFile /home/$Benutzer/.ssh/quake

In der ersten Zeile geben wir den Namen der Verbindung an. Hier kann man frei wählen. Als Nächstes geben wir die IP des Rechners an, zu dem wir uns verbinden möchten. Der Port muss angegeben werden, wenn wir einen, vom Standard abweichenden, Port eingestellt haben. In der nächsten Zeile wird der Benutzer angegeben, mit dem wir uns auf dem Rechner einloggen möchten. Sollte man anstelle von Passwörtern SSH-Keys nutzen und hat man mehrere unter ~/.ssh liegen gibt man am besten mit IdentityFile auch noch die richtige Schlüsseldatei an.

Nachdem man die Datei abgespeichert hat, braucht man nun nicht mehr ssh $Benutzer@$IP -p $Portnummer -i ~/.ssh/quake eingeben, sondern es reicht ganz bequem ssh quake.

Linux | OSBN

Entferntes Verzeichnis über SSH lokal mounten

Ich arbeite recht oft mit SSH, um auf andere Rechner zuzugreifen. Ab und zu finde ich es recht angenehm, wenn ich ein Verzeichnis, dass eigentlich auf einem Server liegt, lokal mounten kann. Mit sshfs ist das kein Problem.

Erst einmal erstellt man sich auf dem Rechner vor dem man sitzt an einer Stelle an der man Lese- und Schreibzugriff hat ein Verzeichnis. Am besten im eigenen Home-Verzeichnis.

mkdir sshfs

Das Verzeichnis muss nicht zwangsläufig sshfs heißen. Einfach einen Namen angeben, mit dem man etwas anfangen kann.

Nun muss man eigentlich nur noch das gewünschte Verzeichnis des entfernten Rechners in dieses Verzeichnis mounten. Hierzu reicht ein recht simpler Befehl.

sshfs $Benutzername@$Rechner:/Verzeichnis/auf/dem/Rechner sshfs

Bei $Benutzername muss man den Benutzernamen angeben, mit dem man sich auf dem entfernten Rechner mit SSH einloggen kann. $Rechner ist der Name/IP des entfernten Rechners. Und /Verzeichnis/auf/dem/Rechner ist eben das Verzeichnis auf dem entfernten Rechner, dass man lokal mounten will. Sshfs ist das Verzeichnis, dass wir gerade eben lokal angelegt haben.

Wechselt man nun in das lokal angelegte Verzeichnis findet man dort den Inhalt des entfernten Verzeichnisses vor und kann damit arbeiten, wie wenn alles lokal vorhanden wäre. Nur mit einer kleinen Ausnahme. Es gibt oft eine kleine Verzögerung, wenn man z. B. in ein Unterverzeichnis wechselt.

Aushängen kann man das Verzeichnis wieder, in man einfach folgenden Befehl absetzt.

fusermount -u ~/sshfs

Linux | OSBN