SSH-Befehle scheitern an csh? So beheben Sie Shell-Kompatibilität in Ihrem Code

Ein Entwicklerteam bemerkte ein rätselhaftes Verhalten: Während eine manuelle WP-CLI-Testverbindung über SSH problemlos funktionierte, scheiterte die automatische Pfaderkennung für WordPress bei derselben Verbindung. Der Grund lag nicht in den Anmeldedaten oder Berechtigungen, sondern in der Shell-Kompatibilität des Servers.

Nach intensiver Fehlersuche stellte sich heraus, dass der betroffene Server standardmäßig die C-Shell (csh) als Login-Shell nutzte – eine Konfiguration, die bei japanischen Hosting-Anbietern wie Sakura Internet häufig vorkommt. Während moderne Systeme meist Bash oder Zsh verwenden, verarbeitet csh Befehle wie 2>/dev/null oder [ -f path ] nicht korrekt, was zu Fehlern wie unknown primary or operator führte.

Warum csh Befehle falsch interpretiert

Die C-Shell (csh) und ihre Weiterentwicklung tcsh folgen einer anderen Syntax als die in der Unix-Welt weit verbreiteten Bourne-kompatiblen Shells wie Bash oder sh. Während Letztere Standard-POSIX-Operationen wie Umleitungen (2>/dev/null) oder Bedingungsprüfungen (-f) problemlos verarbeiten, wirft csh Fehler aus:

• 2>/dev/null – Umleitung von Standardfehlerausgaben
• [ -f path ] – Prüfung auf Dateiexistenz
• for X in ...; do ... done – Schleifenkonstrukt
• cmd1 && cmd2 – Logische Verknüpfung von Befehlen
• \( ... \) – Unterausdrücke

Diese Unterschiede führen dazu, dass selbst einfache Befehle in csh scheitern, obwohl sie auf bash-kompatiblen Systemen fehlerfrei laufen. Ein klassisches Beispiel aus dem Fehlerprotokoll:

find: 2: unknown primary or operator

Hier wurde versucht, find ... 2>/dev/null direkt an csh zu übergeben – ohne dass die Shell die Umleitung erkennen konnte.

Die Lösung: Shell-Interpretation erzwingen

Das Entwicklerteam hatte bereits eine Teil-Lösung implementiert: Im API-Endpoint test_ssh_profile wurden Befehle mit /bin/sh -c umschlossen, um die POSIX-konforme Interpretation sicherzustellen. Der Befehl sah dann so aus:

result = c.run('/bin/sh -c ' + shlex.quote('echo ok'), hide=True, warn=True)

Doch dieser Fix war nur lokal wirksam. Andere Stellen im Code, die ebenfalls SSH-Befehle ausführten, blieben unberührt – darunter die automatische WordPress-Pfaderkennung oder die WP-CLI-Tests. Nutzer beobachteten daher ein widersprüchliches Verhalten: Der manuelle Test funktionierte, die automatische Erkennung jedoch nicht.

Eine zentrale Hilfsfunktion für konsistente SSH-Befehle

Um ähnliche Fehler in Zukunft zu vermeiden, wurde eine universelle Hilfsfunktion eingeführt, die alle SSH-Befehle standardmäßig durch /bin/sh -c leitet:

def _safe_run(c, cmd, **kwargs):
    """
    Führt einen Befehl sicher über die POSIX-Shell aus.
    
    Args:
        c: Paramiko-Client-Instanz
        cmd: Der auszuführende Befehl
        **kwargs: Optionale Argumente für c.run()
    """
    wrapped = '/bin/sh -c ' + shlex.quote(cmd)
    return c.run(wrapped, **kwargs)

Durch diese Maßnahme entfiel die Notwendigkeit, jeden einzelnen SSH-Befehl manuell anzupassen. Neue Funktionen, die SSH nutzen, erben automatisch die korrekte Shell-Interpretation.

Statische Analyse als zusätzlicher Schutz

Doch selbst die beste Dokumentation oder Code-Review kann menschliche Fehler nicht vollständig ausschließen. Deshalb wurde ein statischer Test entwickelt, der sicherstellt, dass keine direkten c.run()-Aufrufe mit csh-kompatibler Syntax mehr existieren:

def test_no_raw_c_run_with_sh_syntax():
    """
    Überprüft, ob keine direkten c.run()-Aufrufe mit Shell-Syntax mehr existieren.
    """
    for call in find_c_run_calls('site_manager_web.py'):
        arg = call.argument_text
        if contains_sh_syntax(arg):
            assert arg.lstrip("'").lstrip('"').startswith('/bin/sh -c'), \
                f"Direkter c.run()-Aufruf ohne Shell-Wrapping in Zeile {call.lineno}"

Dieser Test wird in der CI-Pipeline ausgeführt und blockiert automatisch Pull Requests, die gegen die Regel verstoßen. So wird verhindert, dass alte Muster erneut eingeführt werden.

Fazit: Zwei Schutzschichten gegen Shell-Portabilitätsprobleme

Aus dieser Erfahrung lassen sich zwei wichtige Lehren ziehen:

1. Grep nach ähnlichen Mustern, sobald der erste Fix implementiert ist.

Copy-Paste-Fehler, die sich über mehrere Code-Stellen erstrecken, sind schwer zu erkennen. Ein sofortiger Cross-Grep nach der ersten Korrektur deckt versteckte Problemstellen auf.

1. Automatisierte Tests für verbotene Muster einführen.

Ein statischer Test, der unerwünschte Syntaxformen erkennt, ergänzt menschliche Disziplin. Die CI-Pipeline übernimmt die Kontrolle und verhindert Rückfälle.

Shell-Kompatibilität zwischen csh, bash und sh bleibt eine häufig unterschätzte Herausforderung – besonders in heterogenen Serverumgebungen. Mit den richtigen Werkzeugen und Automatisierungen können solche Probleme jedoch dauerhaft gelöst werden, bevor sie im Produktionsbetrieb auftreten.