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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
