Utility to scan for unpassworded SSH privkeys?

[Dan Mahoney, System Admin]

On Thu, 23 May 2013, Ben Lindstrom wrote:

Note that my question was about how to build a specific tool, but as 
you've made some good points I'm interested in continuing the discussion 
on this.  Apologies to anyone who finds this thread looking for the same 
sort of tool I was.

> 1.  Set this in /etc/ssh/ssh_config  and advocate people use it.
>     HashKnownHosts
>             Indicates that ssh(1) should hash host names and addresses when
>             they are added to ~/.ssh/known_hosts.  These hashed names may be
>             used normally by ssh(1) and sshd(8), but they do not reveal iden-
>             tifying information should the file's contents be disclosed.  The
>             default is ``no''.  Note that existing names and addresses in
>             known hosts files will not be converted automatically, but may be
>             manually hashed using ssh-keygen(1).
>
> This stops your "known host" issues.

Right.  Know of it and use it.  I've asked on the development for this 
list in the past for a similar option for the "host" option in .ssh/config 
-- i.e. instead of "when logging into this host" set a line that says 
"when logging into a host that matches this hashed name", so instead of:

"host foo" in ssh_config

you'd have hosthash 
4xqLy4bIRGoQjI/B+eaFwQtYHZ8=|apHjHU+VYNEqDkPKZpI8ZPIPraA=

There's still the problem of shell histories, grepping headers of email, 
throwing a port into PROMISC mode, getting it from netflow, and the like.

Bug: ssh-keygen -H doesn't let you specify a path to your known_hosts 
file.

> 2. Discourage people from leaving PRIVATE KEYS on your server.  The only 
> place they should live is on the user's laptop (hopefully password 
> protected) and encourage good ssh-agent usage (something I always 
> advocate to my users and do myself).

In general, I try to advocate this.  It's my feeling that if I say "hey, 
I've encrypted this key for you, you can do X in the future" that's 
enough for me.  Some people trust my system (which lives behind locked 
doors) more than their laptops and use it for dev and jumping-off.

(Insert different rant here about how I want screen and ssh-agent to play 
nicely together).
  
> This stops people from breaking one ssh account, finding a local exploit 
> and stealing other keys to other people's sites.

> 3.  Encourage (disable offending accounts) people using in their 
> ~/.ssh/authorized_keys files for *EACH* key they place.
>
>     from="pattern-list"

(snip)

And yet there's not yet a requirement that dnssec be present for that. 
Different rant. :)

Also, as I *do* log in from many, many IP ranges (friends' houses, 
cellular networks, datacenters), a non-starter for me, and others.  I have 
friends who travel to alaska and work in salmon canneries for six months. 
I'm not about to hunt down the IP range of whatever godawful spotty 
internet they have up there.

I am a big fan of hostsentry for this issue tho.  In some perfect world, 
PAM would also know about this stuff and would present additional 
challenges when logging in from new hosts/ranges.

> This helps protect against "wandering private key syndrome."  As it is 
> locked down a bit more.
>
> Personally if I were going to allow my system to be a general shell 
> server for even close friends.  I'd have cron jobs disabling, deleting, 
> or otherwise ensuring the the last two are respected.  And it would be 
> clearly posted.

That would be why I asked.  Also, I'd like to blog about this, put the 
scripts out there and tell people to use them.  The fact that I couldn't 
find an easy tool to do so is at least a small part of the issue. :)

-Dan

-- 

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------