☰

AutoSSH durch Firewall – Best Practice für viele Geräte im Netzwerk?

tag-icon • tag-icon ssh ansible remote-access ssh-tunnel remote
AutoSSH durch Firewall – Best Practice für viele Geräte im Netzwerk?

Mein Team versucht, eine Lösung zu finden, um per Fernzugriff auf mehrere Linux-Geräte hinter einer Firewall an mehreren Standorten mit jeweils eigenen Firewalls zuzugreifen und diese zu aktualisieren. Traditionell würden wir den physischen Standort des Unternehmens besuchen und die Geräte mit Ansible aktualisieren, das innerhalb ihres Netzwerks ausgeführt wird, oder Änderungen über RDP und individuellen SSH-Zugriff vornehmen. Portweiterleitung ist keine Option, nicht einmal für eine Bastion.

||REMOTE SERVER|| ===> ||LOCATION 1 FIREWALL|| ===> [DEVICE 1, DEVICE 2, ..., DEVICE N]
(executing cmds)  ===> ||LOCATION 2 FIREWALL|| ===> [DEVICE 1, DEVICE 2, ..., DEVICE N]
                  ===> ||LOCATION 3 FIREWALL|| ===> [DEVICE 1, DEVICE 2, ..., DEVICE N]
                  ...
                  ===> ||LOCATION N FIREWALL|| ===> [DEVICE 1, DEVICE 2, ..., DEVICE N]

Was ist die beste Vorgehensweise bei AutoSSH, oder gibt es eine Alternative, die sich für die Wartung dieser Geräte besser eignet? Bisher haben wir zwei Lösungen.

Lösung 1 – AutoSSH für jedes Gerät:

-Stellen Sie von jedem einzelnen Gerät in jedem Netzwerk eine AutoSSH-Verbindung her (potenziell Hunderte pro Standort). Konfigurieren Sie den SSH-Zugriff für jedes dieser Geräte.

Host loc_1_device_1
        HostName localhost
        Port 6000
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint

Host loc_1_device_2
        HostName localhost
        Port 6001
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint
Host loc_1_device_3
        HostName localhost
        Port 6002
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint

Host loc_2_device_1
        HostName localhost
        Port 7000
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint

Host loc_2_device_2
        HostName localhost
        Port 7001
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint

Lösung 2 – AutoSSH nur für Proxy/Jump-Host:

  • Stellen Sie eine AutoSSH-Verbindung von einem einzelnen Proxy (möglicherweise einem sekundären als Failover) in jedem der Netzwerke unserer Kunden her. Konfigurieren Sie für jedes dieser Geräte den SSH-Zugriff auf einen Port auf dem Remote-Server.
Host location_1
        HostName localhost
        Port 6000
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint

Host location_2
        HostName localhost
        Port 6001
        User maintenance
        IdentityFile /home/devops/.ssh/remote_maint

Von dort aus scheint die Verbindung mit oder einer Ansible-Konfiguration für den Proxy-Befehl recht einfach herzustellen .ssh -t location_1 ssh [email protected]

Ich habe einen Proof of Concept für Lösung 2 durchgeführt, bei dem Ansible-Befehle vom Remote-Server ausgeführt wurden, und es scheint gut zu funktionieren, aber andere Teammitglieder wehren sich gegen Lösung 1, bei der ein 1:1-Inventar aller Geräte beibehalten werden soll (was eigentlich der Sinn von Ansible sein sollte?). Was mich bei Lösung 1 beunruhigt, ist, dass Tausende von Geräten gleichzeitig versuchen könnten, Reverse SSH aufrechtzuerhalten, was zu unnötigem Netzwerk-Overhead führen könnte. Außerdem scheint es unnötig viel Arbeit zu sein, Geräte zu diesem Netzwerk hinzuzufügen und daraus zu entfernen.

Gibt es eine andere Möglichkeit, das Problem anzugehen? Bin ich auf dem richtigen Weg oder bin ich verrückt, weil ich denke, der Rest des Teams sei verrückt?

Antwort1

Ich nutze deine Lösung 1, allerdings mit automatischer Vergabe der Portnummern.
So muss ich nicht jedes Gerät einzeln konfigurieren.

Dies geschieht in einem mehrstufigen Prozess. Wenn sich ein Gerät zum ersten Mal verbindet, weiß es noch nicht, welche Portnummer es verwenden muss. Es verbindet sich also per SSH mit dem Server und sendet dabei seine eigene MAC-Adresse.
Der Server weist eine freie Portnummer zu, speichert diese und teilt dem Gerät den Port mit. Das Gerät speichert die Portnummer für alle weiteren Verbindungen.

Anschließend stellt das Gerät mit der Portnummer erneut eine Verbindung her.

Alle Geräte verwenden den gleichen „privaten Schlüssel“, der jedoch nur zum Aufbau eines Tunnels zum Server verwendet werden kann. Um ein Gerät zu verbinden, wird auf jedem Gerät mein öffentlicher Schlüssel gespeichert.

Auf dem Server befindet sich in der Datei authorized_keys ein einfacher Befehl für diesen Schlüssel (das Skript zur Vergabe neuer Schlüssel durch MACs). Der Tunnel muss über-N

command="/home/tunnel/reverse_server/reverse_server.py",no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa <PUBLIC-KEY-FOR-ALL-DEVICES>

Auf dem Server GatewayPorts nosollte die Option in /etc/sshd/sshd_config konfiguriert werden, um externen Portzugriff zu vermeiden.

verwandte Informationen