Ersetzen Sie ProxyJump durch Bash

Ersetzen Sie ProxyJump durch Bash

Ich muss auf einer Remote-Box einige Entwicklungsarbeiten durchführen. Glücklicherweise habe ich Shell-Zugriff, aber ich muss über ein Gateway gehen, bei dem AllowTcpForwarding auf „false“ gesetzt ist.

Ich habe einen Blick in die Dokumentation geworfen und dort steht:

AllowTcpForwarding Gibt an, ob TCP-Weiterleitung zulässig ist. Der Standardwert ist „yes“. Beachten Sie, dass das Deaktivieren der TCP-Weiterleitung die Sicherheit nicht verbessert, es sei denn, Benutzern wird auch der Shell-Zugriff verweigert, da sie immer ihre eigenen Weiterleitungen installieren können.

Wie würde ich vorgehen, um meinen eigenen Forwarder zu installieren (oder zu bauen)? Mein Ziel hier ist die Einrichtung einesRemote-Interpreter mit Pycharmüber SSH und Bindung an einen lokalen Port, die Daten werden über SSH eingespeist, das durch das Gateway und dann an die Entwicklungsbox, auf der der Code tatsächlich ausgeführt wird. Ich stelle mir vor, dass ich irgendwie nc oder ein anderes Unix-Dienstprogramm verwenden könnte, das die Arbeit erleichtert.

Ich weiß, dass ich mit SSH auf meine Remote-Box zugreifen kann, indem ich Folgendes mache:

ssh -t user1@gateway ssh user2@devbox

Aber diese Option ist in PyCharm offensichtlich nicht verfügbar. Ich muss in der Lage sein, einen lokalen Port zu öffnen, damit

ssh -p 12345 localhost
(or variant)

verbindet mich mit user2@devbox. Dadurch kann ich den Remote-Interpreter so konfigurieren, dass er Port 12345on verwendet localhost, um eine Verbindung zur Remote-Box herzustellen.

Antwort1

Solange man ausführen kannsocatlokal und auf gateway(oder sogar nur bashund catauf gateway, siehe letztes Beispiel!) und darfnichtVerwenden Sie ein PTY, um 8-Bit-sauber zu sein. Es ist möglich, einen Tunnel über SSH einzurichten. Hier sind 4 Beispiele, die das vorherige verbessern:

Einfaches Beispiel, das einmal funktioniert

(eine Aufspaltung würde eine SSH-Verbindung pro Tunnel erfordern, was nicht gut ist). Man muss aussteigen, :damit socat den Exec-Befehl akzeptieren kann:

  • Term 1:
    $ socat tcp-listen:12345,reuseaddr exec:'ssh user1@gateway exec socat - tcp\:devbox\:22',nofork
    
  • Begriff2:
    $ ssh -p 12345 user2@localhost
    
  • Term 1:
    user1@gateway's password:
    
  • Begriff2:
    user2@localhost's password: 
    

Durch das Vertauschen der ersten und zweiten Adresse ist der Socket sofort verfügbar

socatmuss das Sagen behalten, also nein nofork:

  • Term 1:
    $ socat exec:'ssh user1@gateway exec socat - tcp\:devbox\:22' tcp-listen:12345,reuseaddr
    user1@gateway's password:
    
  • Begriff2:
    $ ssh -p 12345 user2@localhost
    user2@localhost's password:
    

Verwendung einerControlMasterssh

Ermöglicht das Forken unter Verwendung nur einer einzigen SSH-Verbindung zum Gateway und ergibt dadurch ein Verhalten ähnlich der üblichen Portweiterleitung:

  • Term 1:
    $ ssh -N -o ControlMaster=yes -o ControlPath=~/mysshcontrolsocket user1@gateway
    user1@gateway's password:
    
  • Begriff2:
    $ socat tcp-listen:12345,reuseaddr,fork exec:'ssh -o ControlPath=~/mysshcontrolsocket user1@gateway exec socat - tcp\:devbox\:22'
    
  • Begriff 3:
    $ ssh -p 12345 user2@localhost
    user2@localhost's password:
    

Nur bashverfügbar cataufgateway

Durch die Nutzungbashintegrierte TCP-Umleitungund zwei Halbduplex- catBefehle (für ein Vollduplex-Ergebnis) benötigt man nicht einmal ein Remote- socatoder netcat. Die Handhabung mehrerer Ebenen verschachtelter und maskierter Anführungszeichen war etwas umständlich und kann vielleicht durch die Verwendung eines Remote bash-Skripts besser oder einfacher gemacht werden. Es muss darauf geachtet werden, dass die Fork catnur für die Ausgabe verwendet wird:

  • Term1 (keine Änderung):
    $ ssh -N -o ControlMaster=yes -o ControlPath=~/mysshcontrolsocket user1@gateway
    user1@gateway's password:
    
  • Begriff2:
    $ socat tcp-listen:12345,reuseaddr,fork 'exec:ssh -T -o ControlPath=~/mysshcontrolsocket user1@gateway '\''exec bash -c \'\''"exec 2>/dev/null 8<>/dev/tcp/devbox/22; cat <&8 & cat >&8"\'\'\'
    
  • Begriff 3:
    $ ssh -p 12345 user2@localhost
    user2@localhost's password:
    

Antwort2

Ersetzen Sie ProxyJump durch Bash

Die Idee oben ist gut! Hier ist meine generische ssh_config-Version, wennProxyJumpfunktioniert nichtWeilAllowTcpForwardingauf „Nein“ gesetzt und meine Standard-Shell ist BASH:

ProxyCommand=ssh -T user1@gateway "exec 3<>/dev/tcp/%h/%p 2<&- ; cat <&3 & cat >&3 ; kill $!"
  • -TPseudoterminal-Zuweisung deaktivieren
  • AusführungEs wird kein neuer Prozess (Bash) erstellt
  • 3<>ist einfach eine Umleitung zu einem verfügbaren Dateideskriptor
  • /dev/tcp/…fordert Bash auf, den entsprechenden TCP-Socket zu öffnen.
  • %HUnd%Pwird von Ihrem OpenSSH-Client ausgewertet alsEntwicklerboxUnd22
  • 2<&-schließt STDERR (Sie können es auch nach /dev/null umleiten)
  • Katze <&3 &liest den ausgewählten Dateideskriptor 3 im Hintergrund
  • Katze >&3wird unseren Dateideskriptor im Vordergrund schreiben
  • töte $!wird das "Lesen" tötenKatze <&3Befehl, der im Hintergrund ausgeführt wird, wenn Sie die Verbindung schließen/unterbrechen. Andernfalls würde er weiter ausgeführt werden.

Es könnte ProxyJump für mich in Situationen ersetzen, in denen es auf dem Jump-Server deaktiviert ist, ich aber meinen privaten Schlüssel wirklich nicht dorthin weiterleiten oder Passwörter ohne zusätzliche Verschlüsselungsebene eingeben möchte. Andere SSH_AUTH_SOCK als Root zu verwenden oder Terminalsitzungen vollständig mit Tastenanschlägen aufzuzeichnen, sind beides reale Möglichkeiten.

Achten Sie aber bitte stets darauf, dass Sie keine für Sie geltenden Richtlinien verletzen!

Antwort3

Oh nein, wir hätten Netcat fast vergessen!

Wenn auf Ihrem Jump-Host Netcat (jede Version) vorhanden ist, können Sie es in Ihrer Konfiguration im Allgemeinen anstelle von ProxyJump wie folgt verwenden:

ProxyCommand=ssh -T user1@gateway "exec nc %h %p"

Oder über die Befehlszeile:

ssh user2@devbox -oProxyCommand="ssh -T user1@gateway 'exec nc devbox 22'"

Antwort4

Ich würde einfach einen anderen SSHD einrichten, der auf einem anderen Port läuft.
Bearbeiten Sie die Einstellungen, sodass TCP-Weiterleitung zulässig ist.

cp /etc/ssh/sshd{,-second}_config 

Bearbeiten Sie sshd-second_config

Port 22220
cp /usr/lib/systemd/system/sshd.service  /etc/systemd/system/sshd-second.service

Ändern Sie /etc/systemd/system/sshd-second.service folgendermaßen:

Description=OpenSSH server second instance daemon
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS

Die ExecStart-Zeile kann je nach Version unterschiedlich sein.

systemctl daemon-reload
systemctl enable sshd-second.service --now

Weitere Informationen finden Sie hier:
https://access.redhat.com/solutions/1166283

Jetzt sollten Sie alles weiterleiten können, was Sie möchten.

verwandte Informationen