-
Notifications
You must be signed in to change notification settings - Fork 344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for SSH's ProxyJump command #1073
Comments
Hi @jameskirsop - What are the parameters sent to the device as login credentials. 10.0.0.5:22 doesn't match with host details. |
Sorry @rahkumar651991, I don't understand the question. I've intentionally removed and masked login credentials to ensure device security: The provided sample SSH Config File indicates that a connection to |
can you share the output for this command.
|
@jameskirsop can you try with something like this Host host_b Host host-a |
FYI, here is what I do in Netmiko for ProxyJump (Paramiko under the hood). It only works with a single ProxyJump host, however: https://github.com/ktbyers/netmiko/blob/develop/netmiko/base_connection.py#L904 You are welcome to reuse in PyEz if it helps. |
I've the very same problem. You can workaround this by running a SSH Socks proxy through your proxy machine. e.g. you do something like
This should open a socks5 proxy on localhost:1080 to proxy jump when ssh'ing to your host. Then, all you need is something like
btw. I'd argue this is not a low priority enhancement. It's quite common to run DMZ/bastions to separate your prod devices from your corp network. Some people do that by blocking end-to-end connectivity and forcing you to jump through a proxy like the author and I are forced to. With that being said, I do think this is not really an issue of py-eznc but down the path in ncclient which does not allow more complicated Paramiko customization. |
Take the following SSH Config file example:
This module ignores the ProxyJump line and tries to connect to the host directly, ignoring the provided configuration.
This is tangentially referenced here.
When calling from within NAPALM, the following is output in debug mode suggesting the root of the fault is with this module:
Calling
ssh -F ~/path/to/ssh_config_file [email protected]
from the command line on the same host succeeds with no SSH connectivity issues.The text was updated successfully, but these errors were encountered: