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 12345
on verwendet localhost
, um eine Verbindung zur Remote-Box herzustellen.
Antwort1
Solange man ausführen kannsocat
lokal und auf gateway
(oder sogar nur bash
und cat
auf 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
socat
muss 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 einerControlMaster
ssh
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 bash
verfügbar cat
aufgateway
Durch die Nutzungbash
integrierte TCP-Umleitungund zwei Halbduplex- cat
Befehle (für ein Vollduplex-Ergebnis) benötigt man nicht einmal ein Remote- socat
oder 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 cat
nur 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.