Make use of ssh_config where possible

[bitprophet]

Description

Paramiko offers an API for reading users' SSH config settings. We can use this, at the very least for host aliasing/settings (e.g. default SSH username different from local username; host "foo" actually having hostname of "bar"; etc) although the more esoteric settings may not be supported by Paramiko itself, such as agent forwarding.

The Paramiko SSHConfig class API is pretty basic: just parse a class, then lookup a hostname. For some silly (?) reason it lowercases the key names (so one gets forwardagent instead of ForwardAgent) but I guess that doesn't present a problem.

Main question is how to integrate the host info with env.hosts, env.user and so forth. ssh_config files, from Fabric's perspective, can only really serve two purposes. Here's a sample ssh_config file:

Host foo
HostName bar
User johndoe

Host *
User jdoe

Someone using Fabric with this file could expect the following:

Additional "DNS"-like mappings

@hosts('foo') results in Fabric actually trying to connect to the hostname bar.

Since this is just a supplement to Fabric's functionality, it should probably be on by default, with an option for deactivating it.

In terms of what is displayed to the user, offhand I'd display the "key" hostname (foo) but possibly have debug output show bar, or show something like foo (bar) perhaps.

Username overrides

In the absence of env.user being set at module level or via a host string in @hosts or similar, the sample config file above would result in connections to foo using the username johndoe, and connections elsewhere using jdoe (this "falling through" is due to how SSH and Paramiko interpret ssh_config files -- Fabric would not be doing this itself.)

When the username is set by the Fabric fabfile or CLI flags, however, it gets a bit trickier. I think it obvious that a full host string would take precedence, i.e. @hosts('user@host') would never be overridden by an ssh_config file. But what about a globally set env.user versus an ssh_config with a host-specific user (such as Host foo above)?

This will entail a little more thought (though in this specific example I'd argue that the more specific setting, across both Fabric and ssh_config, should win -- just like how ssh_config-only things resolve.)

---

Originally submitted by Jeff Forcier (bitprophet) on 2009-07-20 at 04:59pm EDT

Attachments

• ssh_config.patch
• ssh_config_v2.patch

Relations

• Related to Allow for storing/using metadata about hosts #4: Allow for storing/using metadata about hosts
• Duplicated by Shortcuts as in .ssh/config #259: Shortcuts as in .ssh/config
• Related to SSH key forwarding #72: SSH key forwarding

[bitprophet]

Jeff Forcier (bitprophet) posted:

---

Massive overhaul of description.

---

on 2009-12-19 at 07:59pm EST

[bitprophet]

Ustun Ozgur (ustun) posted:

---

Does the dev version honor ~/.ssh/config settings for ports other than 22? I have defined non-standard ports for my servers, but with fabric, I have to specify not only the hostname, but also the port number; even though with ssh I can just login. I can file a new ticket if it isn't so.

---

on 2010-07-07 at 04:01am EDT

[bitprophet]

Jeff Forcier (bitprophet) posted:

---

No work has been done on the ticket at this point in any branch, so your ssh_config file shouldn't be read at all at this point in time -- it won't affect Fabric in any way.

When we do implement this feature, it'll definitely honor the Port specifier, since we already have support in Fabric for port specification.

---

on 2010-07-07 at 09:35am EDT

[bitprophet]

Kirill Pinchuk (cybergrind) posted:

---

2Ustun Ozgur: here is patch that add basic support of .ssh/config file (only hostname, port and user).

2Jeff Forcier: if you want merge this into master branch, I can clear code

---

on 2010-07-07 at 10:44am EDT

[bitprophet]

Morgan Goose (goosemo) posted:

---

Have this imported into a branch, need to make docs and tests.

---

on 2011-02-03 at 02:50am EST

[bitprophet]

Now that #72 is done, this feature can & should use ForwardAgent [yes|no] as another way to tickle env.no_agent_forward.

EDIT: and we should probably tickle that to default to False if not present in ssh_config, it's more secure.

[bitprophet]

The core user/host/port aspect of this (including all docs, tests etc) has been implemented; remaining is the SSH key aspect, plus the timeout/num-connections. Not sure if it makes sense to set those inside normalize() like @cybergrind's patch does, or to set them as late as possible in connect -- will take a look soon.

[bitprophet]

Gonna mark this done, at least until anybody finds more bugs in it :)

There are additional potential config settings we could pull in but those were not worth doing at this point in time -- they really want a serious overhaul to state.env so we can intelligently merge default values + user-set-in-env values + from-ssh_config values. We have a half-assed version of this for some things already but I didn't feel like extending that. Want to get 1.4 done soon...