IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: SSH (Seite 2 von 2)

Linux Backintime Datensicherung / Backup

Kaum schreibe ich etwas zur Datensicherung meines FreeBSD Notebooks, schon kommt die Frage, wie ich einen/meinen Linux Desktop sichern würde….

Um es kurz zu machen, ich nutze dazu seit langem bereits das Programm backintime. Es arbeitet mit rsync und hardlinks ebenfalls bietet es die Möglichkeit seine Sicherungen auf alle möglichen Ziele zu schieben, so auch per SSH nach irgendwo.

Wer rsnapshot für Unix Server kennt… Es ist so ähnlich nur bei Bedarf mit GUI. Zusätzlich lässt sich noch schnell und einfach etwas Krypto ins Spiel bringen. Die Datensicherungen lassen sich so sehr schnell und vor allem einfach erstellen und wiederherstellen. Probiert es einfach mal!

Fragen? Dann fragen.

Siehe auch: ZFS Encryption

Fragen? Einfach melden.

Parallel SSH: Kommandos auf vielen Servern gleichzeitig ausführen

Auf fünf Servern den Besitzer einer Datei ändern geht schnell. Bei 21 wird es zäh. Puppet oder Chef für einen Einzeiler hochzufahren ist Kanonen auf Spatzen. Ich nutze dafür seit Jahren pssh (Parallel SSH). Perfekt für Bash-Einzeiler, die auf vielen Systemen gleichzeitig laufen müssen.

Installation

pssh braucht Python. Die Installation geht über pip:

pip install parallel-ssh

Voraussetzung ist ein funktionierender SSH-Agent mit geladenem Key:

ssh-agent && ssh-add

Server gruppieren

Ich lege im Home einen Ordner pssh/ an und sortiere die Server in Textdateien nach Gruppen: alle Webserver, alle Mailserver, alle Server an einem Standort. Wenn ich dann ein Kommando auf einer bestimmten Gruppe ausführen will, muss ich nicht mehr nachdenken.

$ cat ~/pssh/srv.aps.ber.txt
srv.aps01.ber
srv.aps02.ber
srv.aps03.ber
[...]
srv.aps21.ber

Kommando absetzen

Das Beispiel: Auf allen 21 Applikationsservern in Berlin den Besitzer eines Scripts ändern und das Ergebnis prüfen.

$ pssh -h srv.aps.ber.txt -l root \
    -o ~/pssh/out-$(date +"%m-%d-%y_%H:%M:%S") \
    "chown aglp02:aglp02 /home/aglp02/del_import_sync.sh; \
     ls -la /home/aglp02/del_import_sync.sh;"
[1] 10:17:35 [SUCCESS] srv.aps17.ber 22
[2] 10:17:35 [SUCCESS] srv.aps03.ber 22
[3] 10:17:35 [SUCCESS] srv.aps01.ber 22
[...]
[21] 10:17:37 [SUCCESS] srv.aps18.ber 22

Die Server werden nicht nacheinander abgearbeitet, sondern gleichzeitig. 21 Server in zwei Sekunden.

Die Parameter

-h — Datei mit der Hostliste.
-l — Benutzername für den SSH-Login.
-o — Verzeichnis für die Ausgabe jedes Servers. Ich lasse mir mit date automatisch einen Unterordner mit Zeitstempel erstellen, damit die Ergebnisse zugeordnet bleiben.
Am Ende steht das Kommando in Anführungszeichen.

Ausgabe kontrollieren

Im Output-Verzeichnis liegt pro Server eine Datei mit der Bash-Ausgabe:

$ cat ~/pssh/out-09-22-14_10:17:35/srv.aps01.ber
-rwxr-xr-x 1 aglp02 aglp02 1801 Jan 21 2009 /home/aglp02/del_import_sync.sh

So lässt sich kontrollieren, ob alles sauber gelaufen ist oder ob auf einzelnen Servern nachgearbeitet werden muss.

Einmal vorbereitet, lässt sich pssh schnell in den Arbeitsalltag integrieren. Für alles, was über Einzeiler hinausgeht, greift man dann zu Ansible oder Puppet. Für den schnellen Handgriff auf 20+ Servern ist pssh genau richtig.

Siehe auch: Z Shell als bessere Shell

Fragen? Einfach melden.

Mosh – mobile shell

Langsame SSH Verbindungen sind nicht nur nervig, sie regen mich auf und reizen mich unnötig. Ich werde verrückt, wenn ich etwas in ein Terminal tippe und versetzt eine Rückmeldung über meine Eingaben bekomme. Und wehe man hat sich vertippt.

Besonders wenn man „mal eben“ unterwegs die Welt retten muss und das Terminal hängt oder durch die wechselnde IP Adresse am mobilen Client gleich die ganze Verbindung gekillt wird.

OK, gegen die gekillte Verbindung hilft screen und gegen Vertipper, aufpassen und der Umweg über ein Textfile (copy & paste). Beides sind Notnägel, nicht wirklich dafür gedacht und nicht DIE Lösung.

Vor kurzem hatte ich das Problem auf einigen, weit entfernten, Systemen arbeiten zu müssen. Auf dem Weg dort hin hatte ich leider mit 60 – 80% Paketverlust zu kämpfen. So ist natürlich kaum ein Arbeiten möglich. Glücklicherweise erinnerte ich mich daran mal etwas von Mosh gelesen zu haben. Mosh ist ein sehr guter Name, denn er ist in meinem Hirn hängen geblieben.

Ich bin so begeistert von dem Programm, dass ich es einfach einmal kurz verlinken muss.
https://mosh.mit.edu/

Es lässt sich grob bedienen wie ssh, muss auf dem Client und dem Server installiert sein und arbeitet am Ende mit UDP Paketen. UDP?!?!? Japp UDP…. Genau erlesen kann man es auf der Webseite vom Projekt und dort werden direkt ein paar Bedenken erschlagen hinsichtlich Verschlüsselung und Konsistenz.

Auf meinen Arbeitsplätzen gehört es in jedem Fall ab jetzt zur standard Ausstattung.

So long….

Fragen? Einfach melden.

E-Mail-Benachrichtigung bei Root-Login einrichten

Kein Server lässt sich zu 100 Prozent absichern. Wenn sich jemand eine Root-Shell öffnet, will ich das zeitnah wissen. Nicht erst wenn Kunden sich melden oder Abuse-Mails eintrudeln. Eine kurze E-Mail mit IP-Adresse und Zeitstempel bei jedem Root-Login gibt zumindest einen Anhaltspunkt.

Vorweg: Das ist kein Security-Feature. Ein Angreifer mit Root-Rechten kann die Benachrichtigung deaktivieren, die Mail abfangen oder die .bashrc löschen. Es ist Schlangenöl, wenn man es als Schutzmaßnahme verkauft. Aber als ergänzender Hinweis funktioniert es gut, weil die Mail meist schon raus ist bevor der Angreifer sie verhindern kann. Vorausgesetzt, die Mail geht an einen anderen Server.

Variante 1: .bashrc

Die einfachste Methode. Eine Zeile in /root/.bashrc schickt bei jedem Öffnen einer interaktiven Shell eine Mail:

echo 'ALERT - Root Shell Access (ServerName) on:' `date` `who` | mail -s "Alert: Root Access from `who | cut -d'(' -f2 | cut -d')' -f1`" root-logins@example.com

Das Ergebnis sieht dann so aus:

Subject: Alert: Root Access from 203.0.113.42
ALERT - Root Shell Access (bsd01) on: Mi 12. Mär 14:22:03 CET 2026 root pts/0 2026-03-12 14:22 (203.0.113.42)

Damit die IP-Adresse statt eines Hostnamens in der Mail steht, sollte der SSH-Server keine DNS-Abfragen machen:

# /etc/ssh/sshd_config
UseDNS no

Variante 2: PAM

Robuster als die .bashrc-Methode, weil PAM vor der Shell greift und nicht so leicht umgangen werden kann. In /etc/pam.d/sshd am Ende:

session optional pam_exec.so /usr/local/bin/login-notify.sh

Das Script /usr/local/bin/login-notify.sh:

#!/bin/sh
[ "$PAM_TYPE" = "open_session" ] || exit 0
echo "SSH Login: $PAM_USER von $PAM_RHOST auf $(hostname) um $(date)" | \
  mail -s "SSH Login: $PAM_USER@$(hostname) von $PAM_RHOST" root-logins@example.com

PAM setzt die Umgebungsvariablen PAM_USER, PAM_RHOST und PAM_TYPE automatisch. Das Script prüft auf open_session, damit es nur beim Login feuert und nicht beim Logout.

FreeBSD

Unter FreeBSD heißt die PAM-Konfiguration /etc/pam.d/sshd (gleicher Pfad). Statt mail steht dort mailx zur Verfügung, oder man nutzt direkt sendmail. Die .bashrc-Variante funktioniert genauso, die Datei liegt unter /root/.profile wenn csh/tcsh die Standard-Shell ist.

Einordnung

Login-Benachrichtigungen ersetzen kein Monitoring und kein Intrusion Detection System. Sie sind ein einfacher Stolperdraht, der in der Praxis überraschend oft hilft. Nicht weil er einen Angriff verhindert, sondern weil er die Reaktionszeit verkürzt. Wenn um drei Uhr nachts eine Login-Mail von einer unbekannten IP kommt, weiß man dass etwas nicht stimmt.

Wer den SSH-Zugang selbst härten will: Multi-Faktor-Authentifizierung mit Google Authenticator macht einen erfolgreichen Login ohne den zweiten Faktor deutlich unwahrscheinlicher. Fragen? Einfach melden.

SSH Brute Force

Es ist ja nicht zu glauben… Da scheint eine ganze Chinabude nichts weiter zutun zu haben als SSH Burte Force Attacken durchlaufen zu lassen. Dieser Netzowner geht mir gerade tierisch auf die Nerven. Ich bekommen durchgehen Angriffe aus Netzen bei dem er der Eigentümer ist. Das ist im Moment auch echt massiv 🙁

netname: CHINANET-JS
descr: CHINANET jiangsu province network
descr: China Telecom
descr: A12,Xin-Jie-Kou-Wai Street
descr: Beijing 100088
country: CN
admin-c: CH93-AP
tech-c: CJ186-AP
mnt-by: MAINT-CHINANET
mnt-lower: MAINT-CHINANET-JS
mnt-routes: maint-chinanet-js
changed: hostmaster@ns.chinanet.cn.net 20020209
changed: hostmaster@ns.chinanet.cn.net 20030306
status: ALLOCATED non-PORTABLE
source: APNIC

role: CHINANET JIANGSU
address: 260 Zhongyang Road,Nanjing 210037
country: CN
phone: +86-25-86588231
phone: +86-25-86588745
fax-no: +86-25-86588104
e-mail: ip@jsinfo.net
remarks: send anti-spam reports to spam@jsinfo.net
remarks: send abuse reports to abuse@jsinfo.net
remarks: times in GMT+8
admin-c: CH360-AP
tech-c: CS306-AP
tech-c: CN142-AP
nic-hdl: CJ186-AP
remarks: www.jsinfo.net
notify: ip@jsinfo.net
mnt-by: MAINT-CHINANET-JS
changed: dns@jsinfo.net 20090831
changed: ip@jsinfo.net 20090831
changed: hm-changed@apnic.net 20090901
source: APNIC
changed: hm-changed@apnic.net 20111114

person: Chinanet Hostmaster
nic-hdl: CH93-AP
e-mail: anti-spam@ns.chinanet.cn.net
address: No.31 ,jingrong street,beijing
address: 100032
phone: +86-10-58501724
fax-no: +86-10-58501724
country: CN
changed: dingsy@cndata.com 20070416
mnt-by: MAINT-CHINANET
source: APNIC

 

 



Siehe auch: SSH-Server absichern mit MFA, Mal wieder auffällig viele Brute-Force SSH Angriffe…., Raspberry Pi als Angriffsziel: SSH-Brute-Force auf den User pi

Fragen? Einfach melden.

Mehr als nur A-Records

Dass mein DNS-Server DNSsec http://www.kernel-error.de/dnssec beherscht und so meine Zonen schützt, das wissen ja fast alle. Wie man damit nun seinen GPG Schlüssel verteilen kann und/oder die SSH-Fingerprints einzelner Hosts gegen den DNS Server validieren lassen kann…. Dieses findet sich nun hier:

GPG im DNS: http://www.kernel-error.de/dnssec/gpg-im-dns

SSH-Key im DNS: http://www.kernel-error.de/dnssec/ssh-key-im-dns

Fragen? Einfach melden.

SSH Host Keys per SSHFP im DNS veröffentlichen

OpenSSH kann die Fingerprints seiner Host Keys als SSHFP-Records im DNS veröffentlichen. Beim Verbindungsaufbau prüft der Client dann automatisch, ob der Fingerprint des Servers mit dem DNS-Eintrag übereinstimmt — ein wirksamer Schutz gegen Man-in-the-Middle-Angriffe. Ist die Zone zusätzlich per DNSSEC gesichert, kann der DNS-Record selbst nicht gefälscht werden. Die Spezifikation steht in RFC 4255.

Client konfigurieren

Damit OpenSSH beim Verbindungsaufbau SSHFP-Records prüft, muss VerifyHostKeyDNS aktiviert werden. Global für alle Benutzer in /etc/ssh/ssh_config:

VerifyHostKeyDNS yes

Oder nur für die aktuelle Sitzung:

ssh -o "VerifyHostKeyDNS=yes" server.example.de

SSHFP-Records erzeugen

Am einfachsten direkt auf dem Server mit ssh-keygen — das erzeugt die fertigen DNS-Records für alle vorhandenen Host Keys:

ssh-keygen -r server.example.de.

Ausgabe (Beispiel mit RSA, ECDSA und Ed25519):

server.example.de. IN SSHFP 1 1 47890eecc9a2893061734b07b8f60caa1a856148
server.example.de. IN SSHFP 1 2 b2518ad49cc2adf517d3f6a9faaf4017abc2c3e3...
server.example.de. IN SSHFP 3 1 3dd9de0dcf1523341b45a53f1d57043609e26c62
server.example.de. IN SSHFP 3 2 e1c76bd66b5a0641789b0b37be5b80ae3f6395c1...
server.example.de. IN SSHFP 4 1 a1b2c3d4e5f6...
server.example.de. IN SSHFP 4 2 d4e5f6a7b8c9...

Aufbau des SSHFP-Records

Ein SSHFP-Record besteht aus zwei Zahlen und dem Fingerprint:

hostname IN SSHFP [Algorithmus] [Hash-Typ] [Fingerprint]

Algorithmus:

  • 1 — RSA
  • 3 — ECDSA
  • 4 — Ed25519 (empfohlen, ab OpenSSH 6.7)

DSS (2) ist seit OpenSSH 7.0 standardmäßig deaktiviert und sollte nicht mehr verwendet werden.

Hash-Typ: 1 = SHA-1, 2 = SHA-256. Beide sollten veröffentlicht werden — ältere Clients verstehen nur SHA-1, neuere bevorzugen SHA-256.

Prüfen

Mit dig lässt sich prüfen, ob die Records im DNS angekommen sind:

dig +short server.example.de SSHFP
1 1 47890EECC9A2893061734B07B8F60CAA1A856148
1 2 B2518AD49CC2ADF517D3F6A9FAAF4017ABC2C3E3...
3 1 3DD9DE0DCF1523341B45A53F1D57043609E26C62
4 2 D4E5F6A7B8C9...

Wichtig: Bei der DNSSEC-validierten Abfrage muss das ad-Flag (Authenticated Data) gesetzt sein — sonst ist die Antwort nicht vertrauenswürdig:

dig +dnssec server.example.de SSHFP | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

Verbindungsaufbau mit SSHFP

Ohne SSHFP-Records im DNS meldet OpenSSH:

DNS lookup error: data does not exist
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

Mit SSHFP-Records und DNSSEC:

debug1: found 4 secure fingerprints in DNS
debug1: matching host key fingerprint found in DNS

secure bedeutet: Die DNS-Antwort wurde per DNSSEC validiert. Ohne DNSSEC steht dort insecure — der Fingerprint wurde zwar gefunden, aber der DNS-Antwort selbst kann nicht vertraut werden. Für echte Sicherheit braucht man beides: SSHFP-Records und DNSSEC.

Strenge Prüfung erzwingen

Optional: OpenSSH anweisen, die Verbindung nur aufzubauen, wenn der Host Key erfolgreich validiert wurde:

Host *
    VerifyHostKeyDNS yes
    StrictHostKeyChecking yes

Damit wird die Verbindung abgelehnt, wenn kein passender SSHFP-Record gefunden wird oder die DNSSEC-Validierung fehlschlägt. Das ist die sicherste Einstellung — setzt aber voraus, dass alle Zielserver SSHFP-Records haben.

Kleiner Aufwand, viel mehr Sicherheit. Fragen? Einfach melden.

SSH/OpenSSH

SSH (SecureShell) ist inzwischen sehr verbreitet. Es hat bzw. sollte Telnet überall ersetzt haben. SSH nutz eine Verschlüsselung um zwischen zwei Rechnern Daten auszutauschen. SSH kann aber noch vieles mehr. Z.B. kannst du mit scp einfach, schnell und sicher Dateien von einem Rechner auf einen anderen Kopieren.
scp dateien user@rechner:/pfad
Du kannst aber auch X-Weiterleitungen sehr einfach realisieren. Hierzu musst du einfach in deine sshd_config folgende Option auf yes setzten.
X11Forwarding yes
Mal angenommen du besitzt ein altes (SEHR) altes Notebook. Dieses Notebook hat gerade noch genug Leistung zum Hochfahren und starten des X-Servers. Dieses Notebook könntest du jetzt als eine Art X-Terminal benutzen. D.h.: du tipperst ein:
ssh -X rechner
in deine X-Konsole und meldest dich nun mit deinen Usernamen an einem Zweitrechner in deinem Netzwerk an, welcher etwas mehr Leistung hat und auch gleich noch die Programme installiert sind, mit denen du jetzt gerne auf dem Notebook arbeiten willst. Du tipperst nach der Anmeldung also ooffice oder was du halt gerade brauchst ein. Darauf bekommst du dann nur die GUI auf dein Notebook. Die gesamte Datenverarbeitung und Rechenleistung für das genutzte Programm kommt nun vom anderen Rechner. Bist du mal über eine sehr schwache Leitung an dein System angeschlossen kann dir die Option -C sehr helfen. Diese sorgt dafür das der gesamte Datenstrom komprimiert wird. So ist die zu übertragende Datenmenge kleiner und alles sollte flotter gehen.
ssh -C rechner

Wie sicher ist dieses SSH denn nun?

Man kann sagen, recht sicher. Es gibt natürlich keine absolute Sicherheit und es hängt auch immer ein großer Teil vom User und der Konfiguration ab. Du solltes also einige Punkte in der Konfiguration seines SSH-Servers ändern. Diese liegt fast immer unter: /etc/ssh/ und schimpft sich sshd_config! – Nur SSH2 Das SSH1 Protokoll gilt als unsicher. Programme wie z.b.: ettercap sind in der Lage hier Kennwörter und Usernamen herauszulesen. Zu dem bietet SSH2 eine ganze Stange mehr an Möglichkeiten. Daher sollte nur das Protocol 2 genutzt werden.
Protocol 2
– Root-Login is nicht Der User Root braucht keinen direkten Login. Wer wirklich von extern auf seinem Rechner administrieren will der kann als User auch su oder sudo benutzen. Da SSH2 wohl kaum zu entschlüsseln ist, wird ein Angreifer es meist mit Brute Force versuchen. Er braucht zu dem Kennwort welches er damit bekommen möchte erst mal einen Usernamen. Da er Root haben will und dieser wohl auch immer auf einer Linux-Kiste zu finden ist, wird er es auch auf diesen Account probieren. Verbieten wir jetzt aber den Login für den User Root kann der Angreifer es sehr lange Probieren.
PermitRootLogin no
– Kein User/Passwort verfahren Die Geschichte mit dem Brute Force hatten wir ja jetzt. Was aber wenn der Angreifer einen Usernamen von unserem System kennt. Dann ist es erstmal nur noch eine Frage der Zeit. Tja und da die meisten User keine „guten“ Passwörter haben….. Viel besser ist es wenn der User ein Zertifikat hat, mit welchem er sich anmelden darf. Weiter unten zeige ich wie es gemacht wird. Hier aber erstmal das User/Passwort verfahren verbieten!
PasswordAuthentication no
Das Public-Key-Verfahren (jetzt kommt die Beschreibung) ist da viel besser. Zuerst bauen wir einen schön langen Schlüssel auf dem Client:
ssh-keygen -b 4068 -t dsa
Nun tauchen im Homeverzeichniss des Users, mit dem wir den Schlüssel erstellt haben, unter: ~/.ssh/ zwei Dateien auf: id_dsa und id_dsa.pub. Den Publickey id_dsa.pub packen wir nun auf den Server. Direkt in die Datei authorized_keys (vielleicht müssen wir diese noch mit der Hilfe von touch anlegen). Die Datei sollte im Homeverzeichniss des zu autorisierenden Users im Ordner .ssh angelegt werden. Haben wir das alles so eingetragen brauchen wir kein Kennwort mehr.
Wie wäre es mit einem Tunnel durch die Firewall?
OK… klingt ja ganz nett. Aber warum sollte ich einen Tunnel in meine Firewall machen? Das kann ich dir erklären. Stell dir mal vor du sitzt mit deinem Notebook in einem Netzwerk wo du dir nicht sicher bist das keiner deine Verbindungen abhört oder gar die Verbindungen über bestimmte Ports blockiert sind. Du willst nun aber eine E-Mail schreiben! Oder bestimmte Ports sonst wie durch diese oder eine andere Firewall verschlüsselt tunneln. Um einen einfachen Tunnel zu basteln musst du jetzt nur noch folgendes machen: Computer2:
ssh -N -R 5555:localhost:22 user@erreichbarer_rechner
Jetzt passiert etwas feines 🙂 Denn nun geht am „erreichbarer_rechner“ der Port 5555 auf und der beamt dann alles durch den Tunnel an Computer2 an den Port 22 weiter. Du kannst nun also sitzen wo du willst. Sobald du versuchst dich auf Port 5555 mit dem Computer „erreichbarer_rechner“ zu verbinden, wird deine Anmeldeanfrage direkt an Computer2 weitergeleitet. So bekommst du also sofort das Login von Computer 2.
ssh erreichbarer_rechner -p 5555
Geil, was?

Siehe auch: SSH-Server mit MFA absichern

Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑