This feature was implemented here and is waiting to be pushed:
I've added a couple of lines to this patch to scratch my own itch:
279 proxy_command = env._ssh_config.lookup(env.host_string).get('proxycommand')
280 if proxy_command:
281 user = env._ssh_config.lookup(env.host_string).get('user', user)
In my use case the usernames of hosts behind the proxy differ so the host declaration also specifies the new User name.
Humm, I was sure that my patch was not covering all the possible features that ProxyCommand can use. Thank you for adding this for the discussion :)
ps.: Sorry for closing/reopening the pull request. Hehe, Even with this big green button, I've clicked in the "Close pull request" on! My bad!
Not having env.use_ssh_config = True in your fabfile with your patch causes fabric to crash.
Other than that little gotcha, great work with the patch. Thank you
Thanks @MTBikerTim! Very nice catch, I'll see what I can do to fix this!
I think we could just ignore it both params when use_ssh_config is not set. (So if hasattr(env, '_ssh_config') or alikes)
And have the documentation reflect that you need to set use_ssh_config=True.
updated pull request! :)
@clarete 👍 I haven't had time to test this + the 'ssh' related change out, but they're at the top of my fab todo list. Hopefully soon.
Thank you very much for your feedback @bitprophet. Tell me if you need any change here :)
I have run into another issue but I'm not sure if it is an issue with ssh(python version), fabric or your patch. Every second or so time I try to execute a command I get the following error:
Traceback (most recent call last):
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/main.py", line 720, in main
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/tasks.py", line 299, in execute
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/tasks.py", line 198, in _execute
return task.run(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/tasks.py", line 112, in run
return self.wrapped(*args, **kwargs)
File "/home/tim/fab/fabfile.py", line 75, in ******
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/network.py", line 465, in host_prompting_wrapper
return func(*args, **kwargs)
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/operations.py", line 970, in run
warn_only=warn_only, stdout=stdout, stderr=stderr)
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/operations.py", line 855, in _run_command
pty, combine_stderr, stdout, stderr)
File "/usr/local/lib/python2.7/dist-packages/Fabric-1.5a-py2.7.egg/fabric/operations.py", line 731, in _execute
File "/usr/local/lib/python2.7/dist-packages/ssh-1.7.14-py2.7.egg/ssh/channel.py", line 213, in exec_command
File "/usr/local/lib/python2.7/dist-packages/ssh-1.7.14-py2.7.egg/ssh/channel.py", line 1114, in _wait_for_event
I'll have to create an issue not sure where just yet though.
Using the ProxyCommand feature
Hi @MTBikerTim, that's weird. The company that I work is using it heavily to deploy our product to our servers and some other maintenance stuff and it seems to work. Is there any specific thing that your command does about the standard input/output?
Also, are you using the ssh command as proxy? Cause this feature works like this:
+------------+ std in/out +-------+ tcp connection +------------+ syscalls +----------------+
| ssh-client | -----------| proxy | -------------- | ssh server | -------- | remote process |
+------------+ +-------+ +------------+ +----------------+
So, we need to make sure that this EOFError is not coming from the forked command in the server side to confirm that this problem is happening between the proxy command and the ssh client. Also, you need to make sure that your proxy command is running correctly.
When it happens? Before happening, can you make sure that your proxy command is running? I think a ps aux | grep your-proxy-command will do the job.
ps aux | grep your-proxy-command
This pull request fails (merged 3e690e0 into 994a76e).
Thanks for the reply @clarete. I should have provided more information in my initial post. My proxy command does appear to be running. This is only occurring for a particular type of server. I'm thinking this is most likely caused by some bug between the prehistoric version of openssh on those servers and python-ssh. I haven't been able to replicate the issue in a test environment yet to be able to narrow down the cause. Sadly I don't have direct access to these servers to rule out your patch even though it seems unlikely to be your patch.
And for the error above I was trying to run a more complex command but a simple run('uptime') will produce the same error.
So not to worry I have determined the approximate cause. It has something to do with my local terminal environment. If I use fabric within screen/byobu it works correctly. If I use a plain bash shell I get errors. I would not have guessed my local environment could have that effect.
Just a heads up, I've opened a pull request in paramiko with the same patch I wrote to ssh. Here it goes: paramiko/paramiko#97
This is in now. Re @trbs, the implementation I ended up going with makes a 100% normal, regular connection to the gateway, so AFAIK that should entail any and all host/user/port/ssh-key/etc support, including sourcing those values from ssh_config. I'm definitely willing to entertain "bugfix" level patches to address this if it turns out not to be the case.
@bitprophet , I updated to git fabric and paramiko and ProxyCommand works for me.