HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
ccontavalli
ssh-ident
Python2015–2020
ccontavalli / ssh-ident

ssh-ident

Different agents and different keys for different projects, with ssh.

2Distinct people
8Mentions
0Explicit recommenders
986GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Different agents and different keys for different projects, with ssh.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year8 dated mentions

Observed mentions: 2015-01-03 07:13:22 UTC to 2020-04-30 11:27:08 UTC.

0122015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2020

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC202

What Hacker News says

8 sources
If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to. See also: https://github.com/FiloSottile/whoami.filippo.io Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to. My "github" key only grants access to my github repos, not to my bitbucket repos or to my DigitalOcean servers, or my Scaleway servers. I have an SSH key for each "thing", and each key is kept in a different keyring via https://github.com/ccontavalli/ssh-ident, _precisely_ to avoid that problem. As an example, an attacker gaining root on my Oracle Cloud free server will not be able to clone all my Github repos with it: I only use that key to
Read the rest
connect to that server, and while I may have the github key unlocked at the same time - that's on a different keyring which the server has no visibility of.
In SSH hacks – a little sanity for remote workers
For SSH, I use one key per service, and manage them via https://github.com/ccontavalli/ssh-ident - to ensure that each connection only has access to the key it should, according to the configuration, have access to. I can't stress enough the importance of doing this - using either this tool, or something similar (like manually managing ssh agents). Using one key only would mean that any server you ssh to has (assuming you forward the ssh auth/roaming) the ability to "forward" that connection, and do evil things with it. See https://blog.filippo.io/ssh-whoami-filippo-io/ for more about it. Having multiple keys and only using an agent with the "right" key for the "thing" mean that each "thing" you SSH to would, in the above scenario, not be able to inflict any damage at all. That is, ssh'ing into your personal dev box wouldn't give the dev
Read the rest
box access to your work github account. It's not "easy" to use ssh-ident, or create and remember which identities should be used where, but it's IMVHO easy _enough_. If anyone knows of a better tool, or a better method, I'm all ears. I've thought about using multiple yubikeys or the like, but all methods I've so far found fall very, very short on usability.
In Ask HN: Developers, how do you keep SSH and web URLs organized at work?
> At the end of a successful login, tsh login command now sends the SSH certificate to an active SSH agent. Will it ever be able to create, and use, a DIFFERENT agent? I use https://github.com/ccontavalli/ssh-ident in order to have a different agent per "kind" of hosts, so that if I mistakenly ssh to Mallory's ssh server with my default agent, they won't be able to, say, also pull all my private Github repos. To use teleport as securely, I'd have to - again - concoct a script or something to "pass through ssh-ident". This is tiresome :|
In Teleport 2.3 Released
I use ssh-ident. It creates a separate ssh agent for each identity you use and you can setup a different identity for each host or ssh argument. And if worse comes to worse, it will prevent someone running off with all the keys you are currently using because instead they only have access to that one agent, not all your agents. The downsides (besides possible security implications of trusting someone else's code to manage your keys) is that tools like rsync and scp won't work straight out of the box. You have to either alias ssh to ssh-ident, or provide the path to ssh-ident yourself. https://github.com/ccontavalli/ssh-ident
In Ask HN: How do you manage your SSH keys?
This is a very valid issue. I have been using ssh-ident* for this reason. You can add keys to ~/.ssh/identities and it'll start up an agent for each identity when you use it. This means if the machine you connect to is indeed stealing your keys, at least they only have one key, not all the keys you're currently using. There are some caveats; such as having to specify what domains/IPs should use which identity, and also having to alias ssh to get it to work nicely. So it's not perfect, but it does solve the problem you talked about. * https://github.com/ccontavalli/ssh-ident
In Why aren’t we using SSH for everything?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.