Is there any solution, or even work on, limiting which keys gets forwarded where?
Nico Kadel-Garcia
nkadel at gmail.com
Fri Oct 16 10:02:58 AEDT 2015
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
More information about the openssh-unix-dev
mailing list