[nycbug-talk] Analyzing malicious SSH login attempts
ike at lesmuug.org
Wed Sep 13 10:35:00 EDT 2006
Hi MW, All,
On Sep 12, 2006, at 9:53 AM, michael wrote:
> Recently, I have been moving toward keys vs. passwords (it makes
> fast and fun). But I still have lingering anxiety that once you have
> my desktop, you have my local network AND my datacenter network AND
> anywhere else I've dropped a key.
> Maybe I should, more seriously, consider the shear hassle of skeys.
To be straight, I've used and loved SSH keys for years- so I'm biased
here, and I feel there's a lot of over-macho info out there about
using keys, and little compiled on the important basics.
I tend to use huge keys, and replace them often- and not muck about
with ssh keychain and the like, its' served me very well.
Basically, I feel that ssh-agent, SSHkeychain, and a other keychain
apps people mention, can be really overwhelming for new key users to
deal with. I've also found them to be 'cumbersome under pressure'
for experienced key users, but that's a matter of taste perhaps.
Since SSH is obviously a critical part of any of my infrastructure
*gulp*, I prefer to keep it really simple. (Again, this is all about
threat models and one's use contexts, right?)
With that, I'll explain what I feel are the important basics of my
key use (some of this obvious stuff to key users), I'm obviously
making suggestions based on my use patterns. For the record, I
manage 'a fistfull' of hardware machines in datacenter and office
enviornments, and run lots and lots of jailed systems. My threat
models are pretty much all based around attacks from the internet.
First, use big keys, period (4096 bit are fabby).
I believe many older systems have problems with anything larger than
4096 bit keys (32 bit architecture issues in older softwares?), but
by today's CPU standards, this isn't really so big. Common
discussion on key size is that it would take serious crackers,
(people with supercomputers), 3-5 years to crack a 4096 bit key
outright. This is assuming network auth. capture and replay. This
is of course only speculation, and it can be assumed people with
supercomputers can do much better these days.
Using 4096 bit keys work just as fast as smaller keys in practical use.
Lock a key with a passphrase, so you unlock them on your local
computer when you use them.
Some admins like the fact that unlocked keys let them jump to-and-fro
between machines without having to enter passwords, I feel this is
silly and have seen borderline irresponsible uses of keys in this
manner. If you don't lock your keys, anyone can use it- and you have
to spend an inordinate amount of time protecting them against
This is where ssh-agent and the other keychain apps come into play,
because they let you authenticate your keys once locally, but again
this opens the door to various and common local threats. Is it
really that cumbersome to enter a passphrase for each ssh login?
**caveat** It does get messy to manage using multiple keys without
ssh-agent. However, a caveat to that caveat, is that using many keys
discourages admins from changing their keys regularly, which I see
as a MUCH larger threat :)
If you lock your private keys with a local passphrase, you can then
happily toss them around to different trusted systems, keep them on
your iPod, whatever you choose to trust.
The threat here is that someone would run a dictionary attack against
your keys themselves, so you still want to be very conservative with
where they live. Also, one must of course trust any machine where
they *unlock* those keys, (any machine which you ssh OUT of).
Your public keys, can be tossed around pretty freely, and placed on
remote systems you simply want to log IN to.
It's a cool way to work, because between savvy admins, there's no
need to deal with passwords when setting up shell account access.
(These keys are ~/.ssh/id_dsa.pub or ~/.ssh/id_dsa.pub respectively)
This is great for shell accounts on systems you don't use, or don't
entirely trust based on it's use. If your not going to ever ssh out
from said machine, there's no reason for you to have your private
keys up there, weather they're locked with a passphrase or not.
RSA or DSA keys?
You decide, this is really a big ongoing debate by the hardcore
crypto folks. RSA is far older, comes from MIT in the late 70's.
DSA comes from the NSA in the mid 90's. Both are believed to be a
secure signature algorithm given 'sufficently long keys'. I believe
the relative age of RSA is what prompted the 'RSAAuthentication yes'
line in sshd_config. In the late 90's, when DSA had become equally
common, it was assumed RSA would be (or had been) cracked. Since
then, it's held up quite well, and at the time of this writing RSA is
only twice as old as DSA (15 years compared to 30 years), so hrmph-
it's all all about calculated risk anyhow, eh? :)
Dissalow password auth on your servers.
On 'high-security' host machines, simply disallow password
authentication alltogether in your sshd_config file- (and noteworthy,
on some systems [FreeBSD 6.x onward for example] one needs to disable
PAM auth. in the config file too, to completely disallow password
This is critical for any online system you wish to protect, password
auth is low lying fruit. A practical personal experience with this
was with the 'SSH1 CRC-32' exploit from 2001, which of course
rendered SSH protocol V1 useless:
So basically, my experience was that systems that disallowed password
auth weren't low enough fruit for the ssh feeding frenzy that ensued-
giving us plenty of time to reconfigure the systems to disallow SSHv1
alltogether, and run around unplugging any hardwired-ssh1 in network
appliances of the time (PDU's, etc...).
At the end of the day an exploit is an exploit- and everything is of
course crackable (including one's brain), but ssh keys keep your
system from being low-lying fruit- which is practical and important
today on the internet.
So my key philosophy is simple- change your keys often, and do
whatever is easiest for you according to your threat and usage models.
An awesome how-to, because it's simple:
> I'm curious, do NYCBUG talk subscribers consider this a "best
> practices" article? Is anything misleading, wrong, missing.. or
Hope my rambling primer is useful to folks out there.
> I am also curious.. where do we draw the line and just *trust* our OS?
When we turn our computers off, IMHO. :P
More information about the talk