Using two agents

[Nico Kadel-Garcia]

On Sun, May 31, 2015 at 2:29 AM, Phil Pennock <phil.pennock at globnix.org> wrote:
> On 2015-05-30 at 11:25 -0400, Nico Kadel-Garcia wrote:
>> The workable, but fugly solution is to load an ssh-agent with the keys
>> you want in environment two, keep a local unencrypted private key for
>> permiter access to environment one stored in a shielded, protected,
>> ideally locally disk partition encrypted location, and set up
>> $HOME/.ssh/config with a "Host" entry to specify that
>> non-standard-location unencrypted key location to use for accessing
>> that permiter host or those perimeter hosts. I don't like this
>> solution myself, but it satisfies all the stated requirements of "I
>> don't want to keep typing my perimeter key passphrase"
>
> This is what we do.  The reliance upon disk encryption and loss of
> passphrase protection is ... "unfortunate".

Yeah. If you have to go that route, it's well worth the extra steps to
restrict the operations available to the passphrase free key. But
that's a whole separate artform.

Hmm. Another fugly approach is to use the first connection, with a
$HOME/.ssh/config set to not forward agents to the target host,
perbaps with an alias of "target-tunnel", and set up an SSH tunnel on
your local server to the remote SSH. Then set up a second entry for
normal connection that goes through the designated local port but
*does* activate ForwardAgent.

I've actually recently done something similar with the 'autossh'
toolkit, to tunnel rsync over SSH connections to where I wanted them,
drilling through a "jumpgate" host. This is also one of those cases
where the sometimes deprecated "chroot" cage approach running an SSH
daemon can be helpful, to use the first access key to access just such
a "jumpgate" server and segregate typical users from seeing each
other's accounts or other system information. I publish updates for
the autossh 'mkchroot.sh' tool at
https://github.com/nkadel/rssh-chroot-tools

>> Mind you, I've never been complete thrilled with ssh-agent. If yo
>> really want to segregate credentials for different environments, you
>> might look into Kerberos based authentication, which can provide a
>> very different approach to finer grained credential management. I just
>> wish I could get it to work with Subversion.....
>
> Each environment is distinct, in locations where we don't fully control
> DNS and where Kerberos is not a plausible solution.  At least, I haven't
> considered it seriously, but I'll think on it some more.  >90% sure it's
> not, given that one of the things I've had to log into those setups to
> do was to fix messed up system clocks.  A bit of a chicken/egg problem
> if that now requires Kerberos.

Well, yes. that's one of the "Just use NTP and use it correctly"
situations pops up. But if the client host is a developer admin laptop
or VM without good configuration management, yeah, life can get pretty
confused. It's aggravated if the Kerberos server is on old, bog stable
hardware on which the motherboard battery has expired, and you reboot
it to migrate data centers, and NTP is not set to do a hard "I'm not
kidding, actually reset this completely no matter how far off you
are".

> When I used subversion with Kerberos, I only used it with https and was
> always fighting some aspect of the lack of consideration for this
> use-case.  Neon would at least allow Kerberos via WWW-Negotiate, as long
> as HTTPS was in use, not HTTP.
>
> -Phil

Yeah, I *wish* svn+ssh could work this way. The activation of a single
user's access and credentials is currently done through "command"
option among the received SSH keys. It would take an entirely
different system to allow Kerberos to do this, but that's more code
than I can take on.