Re: Is there any solution, or even work on, limiting which keys gets forwarded where?

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



Phil Pennock <phil.pennock@xxxxxxxxxxx> 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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux