Netzwerk-Scripting: curl, ssh, rsync

Server kommunizieren ständig miteinander: APIs abfragen, Dateien zwischen Servern synchronisieren, Befehle auf entfernten Maschinen ausführen. Diese Aufgaben heißen Netzwerk-Scripting. Drei Werkzeuge bilden hier das Fundament: curl (HTTP/HTTPS-Requests), ssh (sichere Remote-Shell) und rsync (effiziente Dateisynchronisation).

Alle drei sind auf jedem Linux-Server vorinstalliert und seit Jahren stabil. Ein FISI, der diese drei beherrscht, kann Server-Cluster fernsteuern, Backups zwischen Standorten organisieren und Web-APIs aus Skripten heraus nutzen. Das sind die Werkzeuge mit denen man im Server-Alltag wirklich produktiv ist.

1) Die drei Helden im Überblick

curl, ssh, rsync

curl

Client URL – HTTP/HTTPS-Anfragen

Macht HTTP/HTTPS-Anfragen aus der Shell. Webseiten herunterladen, REST-APIs aufrufen, Dateien per FTP, sogar Mails verschicken. Das Schweizer Taschenmesser für alles was übers Netz spricht. HTTP-Grundlagen siehe K42 L1.

ssh

Secure Shell – verschlüsselte Remote-Shell

Öffnet eine Shell auf einem entfernten Server. Alles verschlüsselt (siehe K08 Kryptografie). Auch zum Übertragen von Dateien (scp/sftp) und für Tunnel/Port-Forwarding. Das Standard-Tool um Server zu verwalten.

rsync

Remote Sync – effiziente Datei-Synchronisation

Synchronisiert Dateien lokal oder über SSH. Überträgt nur Änderungen (nicht ganze Dateien neu) – extrem effizient. Standard für Backups und Server-Deployments.

Wichtig: alle drei laufen über das Netzwerk – aber auch lokal. curl kann z.B. lokale APIs ansprechen (localhost), rsync Verzeichnisse innerhalb derselben Maschine synchronisieren. Du musst nicht zwingend mehrere Server haben um sie zu lernen.

2) curl – HTTP-Requests aus der Shell

Die Basis: curl URL lädt den Inhalt von der URL und gibt ihn auf stdout aus. So einfach wie ein Browser-Aufruf, nur ohne Rendering:

# Einfache GET-Anfrage – Inhalt auf Bildschirm curl https://example.com # In Datei speichern curl -o output.html https://example.com curl -O https://example.com/datei.zip # nimmt Original-Namen # Nur die Header anzeigen curl -I https://example.com # Mit Status-Code (Default ist still bei Erfolg) curl -w "%{http_code}\n" -o /dev/null -s https://example.com # → 200 # Redirects folgen (Default tut es NICHT!) curl -L https://example.com # Silent (kein Progress) plus Show Errors curl -sS https://example.com

Die häufigsten Optionen die du dir merken solltest:

Die wichtigsten curl-Optionen

-X METHOD

HTTP-Methode: GET (default), POST, PUT, DELETE

-d DATA

Daten im Body schicken (impliziert POST)

-H "Header: Wert"

Eigener Header (z.B. Authorization)

-o file

In Datei speichern

-O

Original-Dateinamen behalten

-L

Redirects folgen

-s

silent (kein Progress)

-S

Fehler trotzdem zeigen

-I

nur HEAD (Header allein)

-u user:pass

Basic Auth

-k

SSL-Fehler ignorieren (NUR Testen!)

--max-time N

Timeout in Sekunden

-w "format"

Eigenes Ausgabeformat (HTTP-Code etc.)

-A "agent"

User-Agent setzen

-v

verbose – komplette Kommunikation

Pro-Tipp: zum Testen einer API ist curl -v Gold wert – du siehst die kompletten Request- und Response-Header. curl -I reicht oft schon um zu checken ob ein Server lebt. Auch nützlich: curl -w "%{http_code} %{time_total}s\n" -o /dev/null -s URL – gibt Status und Antwortzeit aus.

3) REST-APIs mit curl ansprechen

Moderne Webdienste sprechen meist über REST-APIs mit JSON. Curl kann das problemlos:

# GET – Daten holen curl -s https://api.example.com/users/42 # POST – Daten senden (JSON) curl -X POST https://api.example.com/users \ -H "Content-Type: application/json" \ -d '{"name":"Anna","alter":25}' # Mit Authorization-Token curl -H "Authorization: Bearer eyJhbGc..." \ https://api.example.com/protected # PUT – aktualisieren curl -X PUT https://api.example.com/users/42 \ -H "Content-Type: application/json" \ -d '{"alter":26}' # DELETE curl -X DELETE -H "Authorization: Bearer ..." \ https://api.example.com/users/42 # Daten aus Datei senden curl -X POST -H "Content-Type: application/json" \ -d @data.json \ https://api.example.com/import # JSON-Antwort mit jq pretty-printen curl -s https://api.example.com/users | jq '.' # Nur ein Feld extrahieren curl -s https://api.example.com/user/42 | jq -r '.email'

Das jq-Tool ist DAS Werkzeug für JSON in Bash – ähnlich wie awk für Spalten-Daten. Mit jq '.users[].email' kannst du selektiv aus komplexen JSON-Strukturen Werte ziehen. Nicht überall vorinstalliert – nachinstallieren mit apt install jq. Mehr zu JSON-APIs in K42b JavaScript.

4) Healthcheck-Skript: curl in der Praxis

Ein klassischer FISI-Anwendungsfall: prüfe regelmäßig ob Server-Endpoints erreichbar sind:

#!/bin/bash # healthcheck.sh – prüft mehrere Endpoints set -euo pipefail ENDPOINTS=( "https://api.example.com/health" "https://www.example.com" "https://example.com/api/v2/status" ) for url in "${ENDPOINTS[@]}"; do code=$(curl -o /dev/null -s -w "%{http_code}" --max-time 5 "$url") if [[ "$code" -eq 200 ]]; then echo "✓ $url → $code" else echo "✗ $url → $code" >&2 # Hier könnte Slack-Alert oder Mail kommen fi done

Solche Skripte landen in cron und laufen alle 5 Minuten. Bei Fehler: Mail an On-Call-Admin oder Webhook an Slack/Teams. Professionellere Lösungen heißen z.B. Prometheus/Grafana, aber für kleine Setups reicht so ein Bash-Skript völlig.

5) ssh – sichere Remote-Shell

Mit ssh user@server öffnest du eine verschlüsselte Shell auf einem entfernten Server. Was du dort tippst läuft auf dem Remote-System, als säßest du davor:

# Interaktiv einloggen ssh anna@server.example.com # Auf anderem Port ssh -p 2222 anna@server.example.com # Einen einzelnen Befehl ausführen (ohne Login-Shell) ssh anna@server "df -h" # Mit mehreren Befehlen ssh anna@server "cd /var/log && tail -n 20 syslog" # Mit Heredoc – mehrzeilige Befehle ssh anna@server <<'EOF' cd /var/www git pull systemctl restart nginx echo "Deploy fertig" EOF

Wie verbindet sich SSH eigentlich? Klick die Schritte:

Was passiert beim SSH-Verbindungsaufbau?

1. TCP-Verbindung

2. Schlüssel-Tausch

3. Server-Identity

4. User-Auth

5. Shell läuft

SSH nutzt asymmetrische Kryptografie: beim ersten Connect speichert dein Client den öffentlichen Schlüssel des Servers in ~/.ssh/known_hosts. Wenn der sich später ändert (z.B. nach Server-Reinstall) → Warnung „WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!". Das ist Schutz vor Man-in-the-Middle-Angriffen – immer ernst nehmen! Mehr zu dem Konzept in K26 PKI.

6) SSH-Keys: passwortlos und sicher

Für Skripte (und überhaupt) willst du nicht jedes Mal ein Passwort eintippen. Außerdem sind SSH-Keys sicherer als Passwörter. Setup in 3 Schritten:

# 1) Schlüsselpaar erstellen (auf Client) ssh-keygen -t ed25519 -C "anna@laptop" # Erstellt: ~/.ssh/id_ed25519 (private) und id_ed25519.pub (public) # 2) Public-Key auf Server übertragen ssh-copy-id anna@server.example.com # Schreibt dein public key in ~/.ssh/authorized_keys auf dem Server # 3) Ab jetzt: passwortloses Login ssh anna@server.example.com # direkt drin, kein Passwort

Wichtig: der private Key bleibt IMMER beim Client. Niemals verschicken, nicht in Git, nicht in Backup-Clouds unverschlüsselt. Der public Key darf überallhin – er ist nur das „Schloss" zu dem dein privater Schlüssel passt.

⚠ Sicherheit: Schutz des Private Keys

Wer deinen private key hat, kann sich auf allen Servern einloggen wo der public hinterlegt ist. Bei ssh-keygen kannst du eine Passphrase setzen die den private key verschlüsselt – musst sie dann pro Session einmal eingeben (ssh-agent merkt sich das). Auf Servern: PermitRootLogin no und PasswordAuthentication no in /etc/ssh/sshd_config setzen – nur Key-Auth zulassen. Erschwert Brute-Force-Attacken massiv.

7) SSH-Konfig: ~/.ssh/config

Wenn du viele Server administrierst, wird ssh anna@server-foo-bar-prod-123.example.com -p 2222 -i ~/.ssh/key nervig. Die ~/.ssh/config macht's elegant:

# ~/.ssh/config Host webserver HostName www.example.com User anna Port 2222 IdentityFile ~/.ssh/id_ed25519 Host db HostName db.internal.example.com User admin ProxyJump webserver # über webserver hopsen Host *.example.com User anna IdentitiesOnly yes

Jetzt reicht ssh webserver für deine ganze Konfiguration. ProxyJump ist super wichtig: wenn ein Server nur über einen Bastion-Host erreichbar ist, hangelt sich SSH automatisch durch. Praxis-Beispiel: viele Cloud-Setups haben einen einzigen öffentlichen Login-Server, von dem aus interne Server erreicht werden (siehe K31 Cloud-Architektur).

8) scp und sftp – Dateien übertragen

Aus SSH abgeleitet: zwei Tools für File-Transfer:

# scp (secure copy) – einmalige Übertragung scp datei.txt anna@server:/home/anna/ # lokal → remote scp anna@server:/var/log/syslog ./ # remote → lokal scp -r ordner/ anna@server:/home/anna/ # rekursiv # Mit anderem Port scp -P 2222 datei.txt anna@server:~/ # Achtung: -P (groß), nicht -p! # sftp – interaktive FTP-artige Session über SSH sftp anna@server sftp> ls sftp> put datei.txt sftp> get fern.txt sftp> bye

Für mehrfache Transfers oder Backup-Szenarien aber meistens rsync nehmen – ist viel effizienter (siehe unten). scp nutze ich nur noch für „mal eben eine Datei rüberkopieren".

9) rsync – die effiziente Synchronisation

rsync ist genial: es überträgt nur die Unterschiede zwischen Quelle und Ziel. Hast du letzte Woche schon ein 10-GB-Verzeichnis übertragen und nur eine 1-KB-Datei geändert? rsync überträgt nur diese 1 KB. Das macht es ideal für Backups und Deployments:

# Grundform: rsync OPTIONEN QUELLE ZIEL # Lokal: Ordner spiegeln rsync -av src/ dest/ # Remote: lokal nach Server rsync -av src/ anna@server:/backup/ # Remote: Server nach lokal rsync -av anna@server:/var/log/ ./backup-logs/ # Mit Fortschritt und Statistik rsync -av --progress --stats src/ dest/ # Lösche im Ziel was in der Quelle nicht (mehr) existiert rsync -av --delete src/ dest/ # Trockenlauf: zeige nur was passieren WÜRDE rsync -av --dry-run --delete src/ dest/ # Bestimmte Dateien ausschließen rsync -av --exclude="*.tmp" --exclude="node_modules" src/ dest/ # Ausschluss-Liste aus Datei rsync -av --exclude-from=excludes.txt src/ dest/ # Über SSH mit anderem Port rsync -av -e "ssh -p 2222" src/ anna@server:/backup/

Die -av-Standardkombination heißt archive + verbose: behält Rechte, Symlinks, Zeitstempel bei und zeigt was übertragen wird. Fast immer was du willst.

10) Der Slash am Ende ist wichtig!

Eine berüchtigte rsync-Falle:

Slash oder kein Slash – mit Folgen

rsync -av src/ dest/

→

dest/datei1, dest/datei2

Slash am Ende: nur den INHALT kopieren

rsync -av src dest/

→

dest/src/datei1, dest/src/datei2

Ohne Slash: das Verzeichnis SELBST kopieren

Dieser Unterschied bringt seit Jahren Admins zur Verzweiflung. Faustregel: am Anfang erst mit --dry-run testen! Dann siehst du was rsync tun würde, ohne dass es passiert. Sobald die Liste sauber aussieht, das --dry-run weglassen und scharf schalten.

11) rsync-Backup-Pattern

Ein klassischer Server-Backup-Job kombiniert rsync mit cron:

#!/bin/bash # /usr/local/bin/server-backup.sh set -euo pipefail QUELLE="/var/www/wichtig/" ZIEL="backup@backup-server.intern:/storage/server1/" LOG="/var/log/backup.log" echo "=== Backup gestartet: $(date) ===" >> "$LOG" rsync -av --delete \ --exclude="*.tmp" \ --exclude="cache/" \ --log-file="$LOG" \ "$QUELLE" "$ZIEL" echo "=== Backup fertig: $(date) ===" >> "$LOG"

In der Crontab: 0 2 * * * /usr/local/bin/server-backup.sh. Erstellt jede Nacht 2 Uhr einen Sync auf den Backup-Server – nur Änderungen werden übertragen, läuft auch bei großen Datenmengen schnell. Mehr zu Backup-Konzepten in K58 Backup-Strategien.

12) Weitere nützliche Netzwerk-Tools

Außer den drei Helden gibt es noch:

wget – Alternative zu curl, oft für ganze Webseiten herunterladen (wget -r).
nc (netcat) – Low-Level-Netzwerk, „Schweizer Messer" für TCP/UDP. nc -zv host 22 testet ob Port 22 offen ist.
nmap – Port-Scanner. nmap -p 1-1000 host findet offene Ports. Nur auf eigenen Systemen! Sonst illegal.
ping, traceroute, dig – Netzwerk-Diagnose (siehe K24 Troubleshooting).
mosh – SSH-Alternative die mit instabilen Verbindungen besser umgeht (mobile, schlechtes WLAN).
tmux, screen – Terminal-Multiplexer. Wenn dein langlaufendes Skript per SSH läuft und die Verbindung abbricht: nichts ist verloren wenn du in tmux/screen drin warst.

13) Sicherheit: was nie tun

Drei Anti-Patterns die du beim Netzwerk-Scripting vermeiden solltest:

curl ... | bash aus unbekannten Quellen. Das ist beliebt für Installer (curl install.sh | bash), aber genau so kannst du dir Malware unterjubeln lassen. Lade die Datei runter, schau rein, dann erst ausführen.
Passwörter im Klartext im Skript. Niemals API-Keys oder SSH-Passwörter hartcodieren. Lies sie aus Umgebungsvariablen ($API_TOKEN) oder einer separaten Konfig-Datei mit eingeschränkten Rechten (chmod 600). Bei größeren Setups: Vaults wie HashiCorp Vault oder AWS Secrets Manager.
curl -k in Produktion. Das -k-Flag ignoriert SSL-Zertifikatsfehler. Praktisch beim Testen mit Self-Signed-Certs lokal, aber in Produktion ein Sicherheitsloch (Man-in-the-Middle-Angriffe möglich). Lieber das Zertifikat korrekt installieren – siehe K26 PKI.

Zusammenfassung

curl: HTTP-Anfragen aus der Shell. -o in Datei, -L Redirects, -s silent, -X METHOD, -d data, -H "Header", -u user:pass. Für JSON-APIs: jq dazu. ssh: verschlüsselte Remote-Shell. Login mit ssh user@host, einzelner Befehl mit ssh user@host "befehl". SSH-Keys via ssh-keygen + ssh-copy-id für passwortlosen Login. ~/.ssh/config für Aliase und ProxyJump. scp/sftp für einmalige Transfers. rsync: effiziente Synchronisation, überträgt nur Diffs. -av Standard, --delete entfernt Ziel-Überschüsse, --dry-run zum Testen, --exclude. Slash am Pfad-Ende ist wichtig: mit = Inhalt, ohne = Verzeichnis selbst. Sicherheit: nie curl | bash aus unbekannten Quellen, nie Passwörter hartcodieren, -k nicht in Produktion.