SNMPv3 in Junos

25.06.2026 · 5 Min. Lesezeit

Wer im Junos-Umfeld unterwegs ist, entwickelt sehr schnell eine gewisse Routine im Umgang mit Konfigurationen. Gerade die Kombination aus klar strukturiertem CLI und der Möglichkeit, Konfigurationen sowohl hierarchisch als auch im set-Format darzustellen, macht es unglaublich einfach, bestehende Setups zu reproduzieren oder auf andere Geräte zu übertragen.

Ein typischer Workflow sieht dabei so aus: Man nimmt sich eine funktionierende Konfiguration, exportiert sie mit show configuration | display set, lädt den Output in einen Editor, passt die wenigen gerätespezifischen Details an und überträgt das Ergebnis per Copy & Paste auf die Zielhardware. Für hierarchische Konfigurationen funktioniert ein ähnlicher Ansatz über load override, load merge oder - etwas eleganter - über load relative direkt im Terminal. Gerade beim Austausch von Hardware, etwa beim Wechsel auf ein größeres Modell, ist das extrem effizient, weil sich in vielen Fällen nur Interface-Namen oder einzelne Hardware-spezifische Parameter unterscheiden, während der Rest der Konfiguration unverändert übernommen werden kann.

Diese Arbeitsweise ist erprobt, schnell und in den meisten Fällen absolut unproblematisch. Bis man auf SNMPv3 trifft.

Der Moment, in dem SNMPv3 nicht mehr mitspielt

SNMPv3 bringt gegenüber seinen Vorgängern ein deutlich robusteres Sicherheitsmodell mit. Authentifizierung und optional auch Verschlüsselung basieren dabei nicht einfach auf statischen Community-Strings, sondern auf kryptographischen Schlüsseln, die an Benutzer gebunden sind.

Was dabei gerne übersehen wird: Diese Schlüssel sind nicht universell gültig. Sie hängen eng mit der sogenannten SNMP Engine ID des Geräts zusammen.

In Junos wird - sofern man es nicht explizit anders konfiguriert - keine feste Engine ID angegeben. Stattdessen generiert das System selbstständig eine eindeutige Engine ID auf Basis gerätespezifischer Parameter. Dazu gehören typischerweise Werte wie MAC-Adressen oder andere hardwaregebundene Identifikatoren. Das Ergebnis ist erwartungsgemäß eindeutig pro Gerät, aber eben auch unterschiedlich zwischen zwei ansonsten identisch konfigurierten Systemen.

Genau hier liegt die Ursache für das spätere Problem.

Warum die Engine ID für SNMPv3 kritisch ist

Um zu verstehen, warum ein einfaches Kopieren der Konfiguration fehlschlägt, lohnt sich ein Blick auf die interne Funktionsweise von SNMPv3.

set snmp v3 vacm security-to-group security-model usm security-name $name group view-all
set snmp v3 vacm access group view-all default-context-prefix security-model usm security-level privacy read-view view-all
set snmp v3 vacm access group view-all default-context-prefix security-model usm security-level privacy notify-view view-all
set snmp view view-all oid .1 include

SNMPv3 nutzt ein sogenanntes User-based Security Model (USM). Ein wesentlicher Bestandteil davon ist die Art und Weise, wie aus einem vom Administrator definierten Passwort tatsächlich ein kryptographischer Schlüssel erzeugt wird. Dieser Vorgang ist nicht trivial und vor allem nicht generisch: Der finale Schlüssel wird aus einer Kombination von Passwort und Engine ID abgeleitet.

Vereinfacht gesagt passiert Folgendes:

Das eingegebene Passwort wird in einem ersten Schritt durch eine Hash-Funktion verarbeitet. Anschließend wird dieses Ergebnis an die Engine ID gebunden, indem die Engine ID in den Key-Derivationsprozess einbezogen wird. Der daraus resultierende Schlüssel ist damit eindeutig an genau diese Engine ID gekoppelt.

Das ist kein Zufall, sondern ein bewusstes Design-Element von SNMPv3. Es stellt sicher, dass ein abgefangener oder extrahierter Schlüssel nicht einfach auf einem anderen Gerät wiederverwendet werden kann, selbst wenn dort ein Benutzer mit identischem Passwort existiert.

Damit wird aber auch klar, warum Copy & Paste hier nicht wie gewohnt funktioniert.

Was beim Kopieren der Konfiguration tatsächlich passiert

Wenn du auf einem Junos-System SNMPv3-Benutzer konfigurierst, speichert Junos in der Konfiguration nicht das Klartext-Passwort, sondern bereits den abgeleiteten, Engine-ID-spezifischen Schlüssel. Das ist genau das, was du später in der display set-Ansicht wiederfindest.

set snmp v3 usm local-engine user $name authentication-md5 authentication-key <hash>
set snmp v3 usm local-engine user $name privacy-aes128 privacy-key <hash>

Kopierst du diese Konfiguration auf ein anderes Gerät, passiert Folgendes:

Das Zielgerät hat – mangels expliziter Konfiguration – eine andere automatisch generierte Engine ID. Die importierte Konfiguration enthält jedoch Schlüssel, die auf Basis der Engine ID des Quellgeräts berechnet wurden.

Aus Sicht des Zielsystems sind diese Schlüssel damit schlicht falsch. Sie passen nicht zur eigenen Engine ID und können folglich nicht für die Authentifizierung oder Verschlüsselung verwendet werden. SNMPv3-Anfragen schlagen fehl, obwohl auf den ersten Blick alles identisch konfiguriert ist.

Warum das oft erst spät auffällt

Besonders tückisch ist, dass sich dieses Verhalten nicht sofort bemerkbar macht, wenn man nicht aktiv SNMP testet. Die Konfiguration lässt sich problemlos committen, es gibt keine offensichtlichen Fehlermeldungen, und auch ein Blick auf die Konfiguration selbst liefert keinen direkten Hinweis auf das Problem.

Erst wenn ein Monitoring-System oder ein SNMP-Client versucht, sich zu authentifizieren, wird klar, dass etwas nicht stimmt. Dann beginnt häufig die Fehlersuche – und die führt nicht selten in alle möglichen Richtungen, nur nicht sofort zur Engine ID.

Der entscheidende Punkt: Engine ID bewusst setzen oder Schlüssel neu erzeugen

Die praktische Konsequenz ist klar: Wer Konfigurationen inklusive SNMPv3-Benutzern zwischen Geräten kopieren möchte, muss sich aktiv um die Engine ID kümmern.

Es gibt dabei zwei saubere Ansätze.

Der erste Ansatz besteht darin, die Engine ID explizit zu setzen und auf allen relevanten Geräten identisch zu halten. Damit wird sichergestellt, dass die aus Passwörtern abgeleiteten Schlüssel konsistent bleiben und problemlos zwischen Geräten transferiert werden können. Dieser Weg ist besonders dann sinnvoll, wenn Geräte als funktionale Einheit betrachtet werden oder Konfigurationen regelmäßig geklont werden.

set snmp engine-id local $wert

Der zweite Ansatz ist, beim Übertragen der Konfiguration nicht die bereits berechneten Schlüssel zu verwenden, sondern wieder mit Klartext-Passwörtern zu arbeiten. In der Praxis bedeutet das, die entsprechenden set-Kommandos so anzupassen, dass anstelle der gespeicherten Hashes die ursprünglichen Passwörter angegeben werden. Das Zielgerät berechnet daraus dann eigene Schlüssel, die korrekt zur lokalen Engine ID passen.

set snmp v3 usm local-engine user $name authentication-md5 authentication-password <hash>
set snmp v3 usm local-engine user $name privacy-aes128 privacy-password <hash>

Fazit

Das Zusammenspiel aus automatisch generierter Engine ID und Engine-ID-abhängiger Schlüsselableitung in SNMPv3 ist ein klassisches Beispiel für gut gemeinte Sicherheit, die in der Praxis für unerwartete Effekte sorgen kann. Gerade in einer Welt, in der Konfigurationen regelmäßig per Copy & Paste zwischen Geräten bewegt werden, ist dieses Detail leicht zu übersehen.

Wer sich dessen bewusst ist, kann das Problem jedoch sauber umgehen. Entweder durch eine bewusst gesetzte, konsistente Engine ID oder durch das gezielte Neuableiten der Schlüssel auf dem Zielsystem.

In beiden Fällen gilt: SNMPv3 ist nicht kompliziert, aber es ist deutlich weniger tolerant gegenüber naiven Kopier-Workflows als ältere Versionen. Genau deshalb lohnt es sich, diesen Stolperstein einmal verstanden zu haben - bevor man das nächste Mal vor einem „funktioniert doch alles identisch“-Rätsel steht.