Мне нужно подключиться к целевому устройству через прокси-сервер, чтобы выполнить некоторые команды на целевом устройстве. Для этого мне нужно открыть туннель S SH для прокси, а затем использовать библиотеку Python для взаимодействия с целью через S SH. Библиотека не может поддерживать прокси-соединения. Эта концепция работает, когда я использую свою оболочку напрямую, чтобы вызвать туннель, а затем использую библиотеку Python для взаимодействия с целью. Теперь мне нужно переместить команду оболочки в мою Python программу.
Я попытался открыть туннель S SH, используя подпроцесс со следующим кодом:
config_file = "path/to/config"
cmd = shlex.split(f"ssh -f -N jumphost-tunnel -F {config_file}")
process = subprocess.Popen(
cmd, stdin=None, stdout=subprocess.PIPE, stderr=subprocess.PIPE,
)
Это создает две проблемы .
Проблема 1
Когда я звоню process.pid, PID отличается от того, что я вижу, когда я выполняю ps aux | grep ssh и замечаю PID в ОС. Он выключен на 1 (то есть: PID от subprocess.pid равен 44196 PID от ps aux равен 44197).
Я хотел бы понять, почему PID выключен на 1. Это связано с к процессу S SH, помещаемому в фоновом режиме при вызове с помощью ssh -f?
Задача 2
Он оставляет туннель зомба ie S SH, поскольку я не могу завершите туннель с помощью subprocess.kill() из-за незнания PID команды tunnel.
Как можно безопасно и надежно завершить туннель S SH после завершения программы? Для некоторого фона мне нужно туннелировать к прокси-серверу и выполнить команду на целевом устройстве через S SH. Целевым устройством является Juniper SRX. Я использую библиотеку PyEZ-junos для взаимодействия с ней. Библиотека использует Paramiko для взаимодействия с устройством Junos, но в реализации библиотеки не используются директивы ProxyCommand или ProxyJump, доступные в OpenS SH, следовательно, вызов подпроцесса инициирует туннель для прокси-сервер. Я не хочу менять внутреннюю часть библиотеки PyEZ для решения проблемы туннелирования.