Einzeiler, um alte Kernel zu entfernen (das gibt auch Speicherplatz frei). Hat bei Linux Mint schon häufig geholfen.

dpkg --list | grep linux-image | awk '{ print $2 }' | sort -V | sed -n '/'`uname -r`'/q;p' | xargs sudo apt-get -y purge

Erklärung

( | verwendet die Ausgabe des vorherigen Befehls als Eingabe zum nächsten)

• dpkg --list listet alle installierten Pakete auf
• grep linux-image sucht nach den installierten Linux-Images
• awk '{ print $2 }' gibt nur die 2. Spalte aus (das ist der Paketname)
• sort -V sortiert die Artikel nach Versionsnummer
• sed -n '/'`uname -r`'/q;p' gibt die Zeilen vor dem aktuellen Kernel aus
• xargs sudo apt-get -y purge reinigt die gefundenen Kernel

sed :

• -n sagte sed es soll still sein
• `uname -r`gibt das aktuell installierte Kernel-Release aus – wir binden es in Backticks ein, so dass die Ausgabe als Teil des Befehls eingebunden wird (Sie könnten dies auch mit  $(uname -r) sehen).
• /something/q sagt stop, wenn Sie ’something‘ (in diesem Fall wird etwas von uname -rausgegeben) – das / umgibt einen regulären Ausdruck.
• p ist Drucken
• das ; ist der Befehl separtor, also /something/q;p sagt quit, wenn du etwas abgleichst, sonst print

Insgesamt wird sed -n '/'`uname -r`'/q;p' die Zeilen ausgeben, bis sie mit dem aktuellen Kernelnamen übereinstimmen.

Wenn du paranoid bist (wie ich), kannst du den letzten Teil xargs echo sudo apt-get -y purge machen, so dass der Befehl zum Bereinigen der alten Kernel gedruckt wird, dann kannst du überprüfen, ob nichts Unerwartetes enthalten ist, bevor du ihn ausführst.

deepl.com Translator

askubuntu.com

Der Beitrag Wenig Speicherplatz verfügbar auf boot – Alte Kernel löschen! erschien zuerst auf jybee.com.

Basis dieses Tutorials für einen sicheren SSH-Zugriff mittels RSA-Schlüsselpaar ist eine neue Debian 8 – 64bit Net-Install ohne grafische Oberfläche.

Der SSH-Server auf Debian ist standardmäßig so eingestellt, dass sich root nicht über SSH einloggen kann. Dies ist schon das erste Sicherheitsmaßnahme, die wir auch nicht abändern sollten. So muss ein Angreifer nicht nur das Passwort erraten, sondern auch den Benutzernamen. Dies sind somit schon zwei Unbekannte.

1. Portfreigabe

Um überhaupt von außerhalb mittels SSH auf unseren Debian-Server zugreifen zu können, müssen wir einen Port im Router freigeben.
Hier bietet es sich an, einen x-beliebigen Port (zB.:12345) zu verwenden und diesen an unseren Server Port weiterzuleiten. Dies ist unser 1. Sicherheitsfeature, da Bots auf der Suche nach Schwachstellen oftmals zufällige IP-Adressen und die gängigsten Ports testet, ob etwas antwortet. Alle 65535 Ports abfragen dauert relativ lange und ist daher nicht sehr geläufig.

Nun erfolgt der erste Zugriff mittels SSH auf unseren Debian-Server.

Beim Klick auf Open sollte folgende Warnung erscheinen. Die ist beim ersten Verbindungsversuch mittels SSH normal. Sollte diese Meldung bei unveränderter Konfiguration erneut erscheinen, dann könnte das System kompromittiert sein. In unserem Fall können wir beruhigt auf „Ja“ klicken.

Nun können wir uns mit unserem Benutzer einloggen.

Nach erfolgtem Login holen wir uns Superuser-Rechte mittels des Befehls su.
Nun möchten wir auch noch den SSH-Port auf unserem Server in einen beliebigen Port ändern. Dafür öffnen wir mit folgendem Befehl mit nano die Konfigurationsdatei von SSHD.

nano /etc/ssh/sshd_config

Da Port 22 der gängige SSH-Port ist, werden wir diesen auch auf einen schwer zu erratenen ändern.
Nun muss die geänderte Konfigurationsdatei gespeichert werden. Danach müssen wir den SSH-Dienst neustarten.

/etc/init.d/ssh restart

Die aktive Verbindung wird dadurch nicht getrennt, da bestehende SSH-Verbindungen von der Änderung nicht betroffen sind. Wir sollten den SSH-Zugriff über den neuen Port erst mit einer neuen Terminal-Session ausprobieren, bevor wir unser aktuellen Terminal schließen.

Bevor wir uns jedoch wieder verbinden, müssen wir unsere Portfreigabe im Router noch auf den neuen Port abändern, da die Portfreigabe ja nun nicht mehr an den Standardport 22 sondern in meinem Beispiel an 41235 weitergeleitet muss.

2. Mailversand bei erfolgten SSH-Login

Eine weitere Sicherheitsmaßnahme ist, dass man sich bei einem erfolgtem SSH-Login per Email informieren lässt. Dafür benutzen wir das Programm sendEmail, was uns ermöglicht, Mails mittels Shell-Script zu versenden. SendEmail (nicht zu verwechseln mit sendmail) ist ein in Perl geschriebener SMTP-Client und kann mit folgendem Befehl installiert werden.

apt-get install sendemail

Um Emails versenden zu können, brauchen wir noch einen SMTP-Server. In der Regel bietet das jeder Freemail-Anbieter an. Da ich meine Webseiten auf all-inkl.com hoste, habe ich dort die Möglichkeit mir dafür extra ein Mailpostfach einzurichten.

Damit bei erfolgreichem Login eine Mail verschickt wird, bearbeiten wir mit dem Editor nano die /etc/ssh/sshrc.

nano /etc/ssh/sshrc

Dort fügen wir unten folgende Zeilen ein:

ip=`echo $SSH_CONNECTION | cut -d “ “ -f 1`
logger -t ssh-wrapper $USER login von $ip
echo „Benutzer $USER hat sich von IP $ip eingeloggt.“ | sendEmail -q -f Absender@server.com -s Servername:Port -xu Benutzername -xp Passwort -t Empfänger@server.com -o tls=yes -u „SSH-Login auf Debian Testmaschine“

Folgende Angabe müssen für den Mailversand angepasst werden:
-q = quiet (Es erfolgt keine Textausgabe im Terminal, wenn die Mail versandt wurde)
-f = from (hier die Absendemailadresse eingeben)
-s = Server (Die Adresse der SMTP-Servers mit nachstehender Portangabe)
-xu = User (Loginname für SMTP-Server)
-xp = Passwort (Passwort für SMTP-Server)
-t = to (Empfängeradresse)
tls sollte auf yes stehen, damit eine verschlüsselte Verbindung mit dem SMTP Server aufgebaut wird.
– u = Subject (Betreff der Email)

Nach dem Speichern der /etc/ssh/sshrc können wir durch das Öffnen einen neuen Terminals den Mailversand testen.

3. Login-Versuche begrenzen mit Fail2Ban

Damit BruteForce-Attacken nicht unendlich viele Loginversuche vornehmen können, begrenzen wir die Anzahl der möglichen Versuche mittels des Programms Fail2Ban. Dieses installieren wir mit folgendem Befehl:

apt-get install fail2ban

4. Unbenutze Ports schließen

Da jeder geöffnete Port ein potenziellen Sicherheitsrisiko darstellt, sollten wir alle Ports schließen, die wir nicht benötigen. Dafür müssen wir erstmal wissen, welche Ports durch welche Programme geöffnet sind. Port sind nicht einfach offen, sondern werden von Programmen geöffnet, welche dann an diesem Port lauschen. Mit folgendem Befehl kontrollieren wir die geöffneten Ports:

netstat -tulpen | grep -v ‚127.0.0.1‘ | grep -v ‚::1:‘

Das Resultat:

Wir sehen direkt unseren Port 41235 mit der Info sshd. Jedoch können wir auch die Dienste rpc.statd, rpcbind und dhclient erkennen. Dhclient ist für den reibungslosen Betrieb mit einem DHCP-Server im Netzwerk zuständig und akzeptiert auch nur entsprechende Pakete. Alle anderen Pakete werden verworfen. Rpc.statd und rpcbind sind jedoch für NFS-Freigaben notwendig. Da ich diese nicht benötige, werde ich diese schließen.

Um die Dienste zu stoppen verwenden wir folgenden Befehle:

service rpcbind stop

service nfs-common stop

Natürlich könnten wir NFS mit folgendem Befehl auch komplett deinstallieren, was ich jedoch nicht getan habe:

apt-get –purge remove nfs-kernel-server nfs-common portmap

Nun sollte die Liste unserer offenen Ports in etwa so aussehen:

5. IPv6 deaktivieren

Solange IPv6 noch nicht produktiv genutzt wird, sollte bzw kann man es ruhigen Gewissens abschalten.
Mit

ip addr show | grep inet6

können wir gucken, ob wir eine IPv6 adresse erhalten haben:

Mit folgendem Befehl können wir IPv6 deaktivieren:

echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6

Nach einem Neustart mit dem Befehl reboot sollten wir keine IPv6-Adresse mehr erhalten:

6. SSH-Login mit RSA-Schlüsselpaar

Ein RSA-Schlüsselpaar ist ein sicherer Weg, sich an seinem SSH-Server zu authentifizieren. Während ein Passwort erraten  oder mittels BruteForce-Attacke durchprobiert werden kann, ist es nahezu unmöglich einen RSA-Schlüssel zu entschlüsseln. Beim Generieren des RSA-Schlüsselpaares werden zwei Schlüssel erstellt: Ein öffentlicher und ein privater. Der öffentliche wird auf dem Server abgelegt und ab dann kann man sich nur noch eingeloggen, wenn man über den privaten Schlüssel verfügt. Vereinfacht vorstellen kann man sich das so, als ob der öffentliche Schlüssel ein Türschloss ist und der private Schlüssel der dazugehörige Schlüssel. Wenn jemand den privaten Schlüssel in die Hände bekommt, muss er auch erstmal wissen, zu welchem Türschloss dieser gehört. Noch dazu kann man seinen geheimen Schlüssel auch noch mit einem Passwort sichern. In der PuTTY-Standardkonfiguration muss man beim Verbindungsaufbau auch den Benutzernamen angeben, mit dem man sich einloggen möchte. Dieser lässt sich aber auch vordefinieren. Dazu später mehr.

Zuerst erstellen wir uns ein Schlüsselpaar. Dies erledigen wir nicht auf dem Server. Ich werde die Erstellung des Schlüsselpaares auf einem Linux-Client als auch auf einem Windows Client erklären.

6.1 RSA Schlüsselpaar unter Linux einrichten

Wir öffnen in unserem Linux ein Terminal und geben folgenden Befehl ein:

ssh-keygen -t rsa

Beim bestätigen mit Enter werden wir „Enter file in which to save the key (/home/demo/.ssh/id_rsa):“ gefragt. Diese Frage können wir einfach mit Enter bestätigen. Wenn wir unseren Schlüssel mit einem Passwort verschlüsseln wollen, müssen wir bei der Frage „Enter passphrase (empty for no passphrase):“ unser Passwort eingeben und nach dem Drücken von Enter dieses noch einmal bestätigen. Nun wird das Schlüsselpaar erzeugt. Dies sollte in etwa so ausehen:

Zu finden ist unser Schlüsselpaar unter dem angegebenen Ordner ~/.ssh:

Nach dem Erstellen des RSA Schlüsselpaares wollen wir die Schlüssel mit folgendem Befehl auf unseren Server kopieren:

ssh-copy-id benutzer@server -p Port

(Falls der Port wie oben beschrieben geändert wurde müssen wir ein „-p“ und nach einem Leerzeichen gefolgt die Portnummer angeben)

Nach der Eingabe von Yes und Bestätigen mit Enter sollten wir unseren Schlüssel auf unserem Server mit

nano ~/.ssh/authorized_keys

aufrufen können.

Machen wir nun ein neues Terminal auf und verbinden uns mit unserem Server, dann wird automatisch der Login mittels des RSA-schlüsselpaares durchgeführt. Jedoch können wir uns immernoch von einem anderen Computer, der den privaten Schlüssel nicht besitzt, immer noch mit Benutzername und Passwort anmelden. Um dies zu verhindern müssen wir auf dem Server in der SSH-Config die Passwortauthentifizierung auf „no“ setzen:

nano /etc/ssh/sshd_config

PasswordAuthentication no

Nun ist ein Login nur noch möglich, wenn man über den privaten RSA-Schlüssel verfügt. Ist für diesen ein Passwort gesetzt, dann benötigt man dieses natürlich auch, um den privaten Schlüssel zu entsperren. Der Login sieht dann in etwa so aus:

Nachdem man den Schlüssel entsperrt hat, ist man sofort eingeloggt:

6.1.1 RSA-Schlüsselpaar in PuTTY-ppk-Schlüssel umwandeln

Wenn wir uns jetzt jedoch zB auch von einer Windows Maschine mittels PuTTY einloggen wollen, brauchen wir dort natürlich auch noch den privaten Schlüssel. PuTTY benötigt den Private Key jedoch im .ppk-Format. Mittels des Programms PuTTYgen lässt sich diese jedoch aus unserem vorhandenen Schlüssel erzeugen:

Nachdem wir nun auf „Save private key“ geklickt haben, können wir den gespeicherten Schlüssel in PuTTY unter Connection >> SSH >> Auth >> Browse einfügen.

6.2 RSA-Schlüsselpaar unter Windows erstellen

Der Beitrag Sicherer SSH-Zugriff mit RSA-Schlüsselpaar auf Debian Server erschien zuerst auf jybee.com.

Um den Hostnamen des Raspberry Pis zu ändern, loggen wir uns erst einmal mit unserem Benutzernamen und dem dazugehörigen Passwort ein.

Dann öffnen wir mittels nano die Datei /etc/hostname mit SuperUser-Rechten:

sudo nano /etc/hostname

In dieser Datei steht nur der Hostname und keine weiteren Infos. Einfach nur „raspberrypi“ mit dem gewünschten Hostnamen ersetzen. Beim Hostnamen sind keine Leerzeichen zu verwenden.

Danach speichern wir mittels Strg + X, y und Enter.

Als nächstes ändern wir die Hosts-Datei mit:

sudo nano /etc/hosts

Auch die hosts-Datei wieder mit Strg + X, y und Enter speichern und schließen.

Nun ist der Raspberry nach einem Reboot mittels

sudo shutdown -r 0

auf seinen neuen Namen „getauft“ und sollte unter diesem im Netzwerk erkennbar sein. Das können wir, wenn wir wieder im Raspberry Pi eingeloggt sind, mit dem einfachen Befehl

hostname

auch nochmal überprüfen.

Der Beitrag Raspberry Pi’s Hostname ändern im Raspbian erschien zuerst auf jybee.com.

lirc_rpi: gpio chip not found!

Nun habe ich ein bisschen gegoogelt und bin darauf gestoßen, dass es Änderungen im Kernel gab und man solle sich damit befassen: Raspberry Pi Configuration Device Tree..

Auch das getan aber als Laie war ich damit etwas überfordert.

Nun bin ich darauf gestoßen, dass man

dtoverlay=lirc-rpi

in die config.txt unter /flash eintragen soll. Siehe hier und hier. ACHTUNG! Damit habe ich mir 4 mal die Installation zerschossen, sodass der Raspberry Pi 2 mit OpenELEC nicht mehr hochfuhr.

Zur meiner Lösung:

Als erstes habe ich /flash mit Schreibrechten gemountet:

mount /flash -o remount,rw

Dann in des besagte Verzeichnis gewechselt:

cd /flash

Dann mit nano die config.txt geöffnet:

nano config.txt

Und dann der entscheidende Unterschied:

device_tree_overlay=lirc-rpi

unten in die config.txt eingetragen

Mit Strg-X, Y und Enter die Datei speichern und schließen.

Nun mittels

reboot

den Raspberry neustarten und siehe da: es funktioniert. OpenELEC startet normal durch.

Wir loggen uns wieder mit putty über SSH ein und checken das ganze nochmal:

dmesg |grep lirc

sollte nun folgendes zutage fördern:

Der Beitrag RPi2 openELEC gpio chip not found! IR-Receiver erschien zuerst auf jybee.com.