Make use of ssh_config where possible #3

Closed
bitprophet opened this Issue Aug 19, 2011 · 8 comments

Projects

None yet

1 participant

@bitprophet
Member

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

Relations

  • Related to #4: Allow for storing/using metadata about hosts
  • Duplicated by #259: Shortcuts as in .ssh/config
  • Related to #72: SSH key forwarding
@bitprophet bitprophet was assigned Aug 19, 2011
@bitprophet
Member

Jeff Forcier (bitprophet) posted:


Massive overhaul of description.


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

@bitprophet
Member

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
Member

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
Member

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
Member

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
Member

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
Member

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 bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Docs, changelog re #3 a6003c0
@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Tweaks to env.port re #138 re #3 7b46e66
@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Skeleton tests re #3 adac252
@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Implementation & tests re #3.
Includes backpedal on host-specific ssh_config settings
overriding env vars. Not feasible with current SSHConfig,
and was conceptually messy anyways.
0ab5469
@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Implement key_filename stuff re #3
Includes a bunch of tightly related changes to network.py,
and tests.
5e704fd
@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Implement ForwardAgent config support re #3.
Also dropping connection/timeout stuff for now, can add that later.
a940e94
@bitprophet
Member

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...

@bitprophet bitprophet closed this Feb 3, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment