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

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

On 2015-10-16 at 12:47 +0200, hubert depesz lubaczewski
wrote:
> But the flip side is that using agent opens access to all keys in it
> from any connected host :(
I scripted a setup which generates different `config` and `known_hosts`
files in ~/.ssh and has a wrapper around invoking ssh which uses those
files.  The wrapper looks in an index file (also generated) to decide
which ssh-keys need to be loaded for which destinations and starts a
dedicated ssh-agent before connecting.

This works well for our use-case.  Persistent connection to a jump-host;
SSH key to reach the jump-host doesn't need to be (and isn't) the key
which is loaded into the agent (so that the key passed around for use
remotely does not grant access to the perimeter).  It's not the cleanest
and requires strict hygiene to protect against people helpfully setting
the internal key to grant access to the perimeter class of machines.

The core boils down to (with some renaming):

    eval $(ssh-agent -s)
    #... stuff including loading the correct keys
    if ssh-add -l >|/dev/null 2>&1 ; then
      true # all is good
    else
      echo >&2 "${0}: WARNING: NO SSH KEYS FOUND LOADED INTO
AGENT"
      eval $(ssh-agent -k)
      exit 1
    fi
    set +e
    ${SSH_CMD:-ssh} -F "${YourSpecialConfigFile:?}" "$@"
    exit_status=$?
    set -e
    eval $(ssh-agent -k)
    exit $exit_status

where the stanzas in the config file should include:

    IdentityFile path/to/perimeter/access
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/your_special_config_file
    StrictHostKeyChecking yes
    ForwardAgent yes

-Phil

Phil Pennock <phil.pennock at globnix.org> writes:
> On 2015-10-16 at 12:47 +0200, hubert depesz lubaczewski wrote:
>> But the flip side is that using agent opens access to all keys in it
>> from any connected host :(
>
> I scripted a setup which generates different `config` and `known_hosts`
> files in ~/.ssh and has a wrapper around invoking ssh which uses those
> files.  The wrapper looks in an index file (also generated) to decide
> which ssh-keys need to be loaded for which destinations and starts a
> dedicated ssh-agent before connecting.
>
> This works well for our use-case.  Persistent connection to a jump-host;
> SSH key to reach the jump-host doesn't need to be (and isn't) the
key
> which is loaded into the agent (so that the key passed around for use
> remotely does not grant access to the perimeter).  It's not the
cleanest
> and requires strict hygiene to protect against people helpfully setting
> the internal key to grant access to the perimeter class of machines.
>
> The core boils down to (with some renaming):
>
>     eval $(ssh-agent -s)
>     #... stuff including loading the correct keys
>     if ssh-add -l >|/dev/null 2>&1 ; then
>       true # all is good
>     else
>       echo >&2 "${0}: WARNING: NO SSH KEYS FOUND LOADED INTO
AGENT"
>       eval $(ssh-agent -k)
>       exit 1
>     fi
>     set +e
>     ${SSH_CMD:-ssh} -F "${YourSpecialConfigFile:?}"
"$@"
>     exit_status=$?
>     set -e
>     eval $(ssh-agent -k)
>     exit $exit_status
>
> where the stanzas in the config file should include:
>
>     IdentityFile path/to/perimeter/access
>     IdentitiesOnly yes
>     UserKnownHostsFile ~/.ssh/your_special_config_file
>     StrictHostKeyChecking yes
>     ForwardAgent yes
If you used the ProxyCommand ssh -W trick with that, you would not need
the ForwardAgent, at which point each internal server would never see
the jumphost key but also the jumphost would never see any of the
internal keys, because they'd be going over the still-encrypted links
that are being forwarded to the internal servers.

This also means that the hostkey checking on the internal servers is
done at your end, and not on the jumphost, so one doesn't need to have
any real trust in the jumphost as it's just acting as a router really.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151020/3536a0ae/attachment.bin>