openssh unix dev - Oct 2015 - Is there any solution, or even work on, limiting which keys gets forwarded where?

Hi,

I'm in a situation where I'm using multiple SSH keys, each to connect to
different set of servers.

I can't load/unload keys on demand, as I usually am connected to at
least 2 of such sets.

But - some rogue "root", could get access to my agent-forwarding
socket,
and in turn, get access to keys loaded to agent (not in terms of
obtaining the key, but being able to use it to log to server he
shouldn't be able to).

As I understand the only solution is to run multiple ssh-agents, and
load each key to only one of them, and then, before connecting, pick
which agent to choose.

But this is pretty tedious, and error-prone.

Is there any ready solution that could be used, or perhaps a work on
incorporating key-filtering to ssh itself?

Best regards,

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

On Thu 2015-10-15 10:34:43 -0400, hubert depesz lubaczewski wrote:
> I'm in a situation where I'm using multiple SSH keys, each to
connect to
> different set of servers.
>
> I can't load/unload keys on demand, as I usually am connected to at
> least 2 of such sets.
>
> But - some rogue "root", could get access to my agent-forwarding
socket,
> and in turn, get access to keys loaded to agent (not in terms of
> obtaining the key, but being able to use it to log to server he
> shouldn't be able to).
>
> As I understand the only solution is to run multiple ssh-agents, and
> load each key to only one of them, and then, before connecting, pick
> which agent to choose.
the better solution is to avoid forwarding an agent entirely, usually by
using a "jumphost" instead.  Have you tried and considered this
approach?  this approach doesn't permit any compromised intermediary
machine any access at all to your agent.

if the intermediary machine (the "jumphost") is jumphost.example, and
you are trying to reach bar.example.com (which is behind the firewall),
you would do:

 ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com

(this can also be placed in ~/.ssh/config, of course).

Another approach, if you find you must forward your agent, is to load
all keys in your agent with confirmation prompt required (ssh-add -c)
so that your local machine is still in control of when the different
keys get used.

There may be other approaches under development (some have been
discussed on this list recently) but please make sure you've considered
the jumphost approach, as it is strictly better than forwarded agents in
all cases except for large data transfers between the two remote hosts.

     --dkg

On Thu, Oct 15, 2015 at 10:34 AM, hubert depesz lubaczewski
<depesz at depesz.com> wrote:
> Hi,
>
> I'm in a situation where I'm using multiple SSH keys, each to
connect to
> different set of servers.
>
> I can't load/unload keys on demand, as I usually am connected to at
> least 2 of such sets.
I *just* went through some of this, to distinguish between github SSH
"deploykeys" and my personal key when connected to a remote server for
which I may wish to publish updates to github.

I personally now set up a .ssh/config with "Host" entries specified
for different services and different "IdentityFile" services, to
ensure use of one local key or the other for a particular "Host" as
designated in .ssh/config. This does not require a real CNAME or valid
DNS for the target host, and lends itself well to automated services
where one upstream git repo requires a different SSH key than another.

This does mean a private key on the server, which is its own risk. But
for automated, unattended git deployment, you make tradeoffs.

                     Nico Kadel-Garcia

> But - some rogue "root", could get access to my agent-forwarding
socket,
> and in turn, get access to keys loaded to agent (not in terms of
> obtaining the key, but being able to use it to log to server he
> shouldn't be able to).
>
> As I understand the only solution is to run multiple ssh-agents, and
> load each key to only one of them, and then, before connecting, pick
> which agent to choose.
>
> But this is pretty tedious, and error-prone.
>
> Is there any ready solution that could be used, or perhaps a work on
> incorporating key-filtering to ssh itself?
>
> Best regards,
>
> depesz
>
> --
> The best thing about modern society is how easy it is to avoid contact with
it.
>                                                             
http://depesz.com/
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Thu, Oct 15, 2015 at 04:15:03PM -0400, Daniel Kahn Gillmor
wrote:
> if the intermediary machine (the "jumphost") is jumphost.example,
and
> you are trying to reach bar.example.com (which is behind the firewall),
> you would do:
>  ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com
We use jump host, but there are literally hundreds of hosts behind it.
And since I often need to run things on multiple hosts, I ssh to jump
host, start tmux session, and ssh from there wherever I need.

Not to mention that in case like above, I would have to type the
password to key two times, which is complicated, to put it lightly, as
I use very long, very secure passphrases.
> Another approach, if you find you must forward your agent, is to load
> all keys in your agent with confirmation prompt required (ssh-add -c)
> so that your local machine is still in control of when the different
> keys get used.
Yeah, but that will (from what I understand from man) re-ask for my
password, which is highly impractical given the above passphrase
situation.

Best regards,

depesz

On Thu, Oct 15, 2015 at 07:02:58PM -0400, Nico Kadel-Garcia
wrote:
> On Thu, Oct 15, 2015 at 10:34 AM, hubert depesz lubaczewski
> <depesz at depesz.com> wrote:
> > Hi,
> >
> > I'm in a situation where I'm using multiple SSH keys, each to
connect to
> > different set of servers.
> >
> > I can't load/unload keys on demand, as I usually am connected to
at
> > least 2 of such sets.
> 
> I *just* went through some of this, to distinguish between github SSH
> "deploykeys" and my personal key when connected to a remote
server for
> which I may wish to publish updates to github.
> 
> I personally now set up a .ssh/config with "Host" entries
specified
> for different services and different "IdentityFile" services, to
> ensure use of one local key or the other for a particular "Host"
as
> designated in .ssh/config. This does not require a real CNAME or valid
> DNS for the target host, and lends itself well to automated services
> where one upstream git repo requires a different SSH key than another.
> 
> This does mean a private key on the server, which is its own risk. But
> for automated, unattended git deployment, you make tradeoffs.
So it's unacceptable for me - I have to have access to production
servers - access to them, without password, from jump host, shouldn't be
possible, but we can use ssh agent - which solves the problem.

But the flip side is that using agent opens access to all keys in it
from any connected host :(

depesz