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