[ale] any suggestions on an automated method for blocking repeated failed ssh login attempts?

[Michael H. Warfield]

Hello,

Good to have triggered some interesting discussion on this.  I can see
that I'll have a VERY lively session if I do my ssh talk at ALE.  Aaron
and I can work out the scheduling details later but I think this will
have to go on the calendar for some upcoming month.  Probably later that
sooner, unfortunately, but we'll make it happen.

On Thu, 2010-12-23 at 16:02 -0500, Jim Kinney wrote:
> On Thu, Dec 23, 2010 at 3:29 PM, Michael H. Warfield <mhw at wittsend.com>wrote:
> 
> >
> >
> > I know I'm doing my IPv6 talk next month for ALE.  Maybe I need to
> > schedule my talk on "Securing the Secure Shell" some time in the next
> > few months as well.  I gave that talk in front of AUUG a while back but
> > I don't think I've delivered it at ALE before.
> >
> > I am all for hearing it! Aaron please contact MHW ASAP before he changes
> his mind! :-)

> At work, I'm prepping an ssh-key repository to ensure that all keys use a
> good password.

I'm not totally sure I perceive the threat vectors you hope to address
or where they stand on an attack tree here, but...  Ok...  Lets work
with this and see where it leads.  Yes, I can see some similarity
between strong passwords on PGP keys and this but the similarity is
somewhat superficial since they keys are used for totally different
things and other environmental factors come into play.

> The repository will generate the ssh keys for the users and
> archive the original, no password key in a vault (literal, steel vault with
> key as text on paper with a barcode for fast input, placed there buy someone
> with a firearms license at the federal level), then the user must enter a
> password to encrypt the key.

As a cryptographer, any system generating keys for a user stands the
hair up on the back of my neck.  It also runs contrary to a number of
strong crypto systems which would preclude it to some extent or another.
To use my analogy a bit further, the idea of generating PGP keys for
users would be totally abhorrent and unacceptable to me and violates
many of the basic PGP principles.  But, these are not the same thing and
this very thing is common in X.509 client certificates where a site
generates a complete PKS12 key and cert pair (which I also think is an
abomination but that's grist for another rant on another day) for a
client and then E-Mails it to them with a transport passphrase (sigh).

> That encrypted key is then copied to their
> thumb drive and the original unencrypted is hashed, wiped and the hash
> stored. Their pub key is placed in the ldap server.The sshd is a modified
> one that locates ssh pub keys from ldap. It is also configured to never
> allow a password entry.

That sounds sort of reasonable but I'm not sure of the value-add in the
complexity of this is unless the real goal is an escrow or backup of the
private keying material.  If that private keying material is intended
primarily for authentication, then I have to feel this is all a bad
idea.  Having a backup for a key used to protect data at rest, such as
PGP keys, is generally a good idea.  Having a backup of private keying
material primarily used for authentication is almost always a very bad
idea.  You don't gain anything by it.  If someone loses an
authentication key, you simply replace the authentication key and reset
the public keys for the authentication and nothing is lost.  If you lose
a key for data at rest, the data is lost.  That's not the case with an
authentication key, like this, though.  I don't see the value in the
keystore and this complicated handoff.

> The complicated (and unwritten) stage is to devise a method that checks the
> connecting users priv key for being still password locked once they log in.
> If it's NOT locked, they are kicked out and the pub key is removed from
> ldap. Not sure yet on how to do this.

I would have to say this is just about impossible and should be
impossible, even in principle, on several levels.  How do you deal with
the case of ssh-agent where the keys have been loaded and cached?  What
if they are hosted on an unlocked smart-card?  How do you detect if they
were originally password protected or not?

What about if they are forwarded using authentication forwarding?  This
is actually an incredibly powerful facility allowing remote system to
remote system authenticated key access while never hosting private
keying materials on any remote server.  How would you deal with
automated processes (not all of this is run by a carbon based life form
pounding  at a keyboard)?

Example...  From an lbb (Little Black Box) located somewhere, a cron job
runs a process that begins a process on a remote server.  The key
required for that process is stored on the lbb and loaded into an
ssh-agent process for the duration of this operation.  More so, the
ssh-agent uses a script to validate each authentication request using
the request acknowledgment hooks.  The remote system, with no private
keying material present, at some point initiates a connection to yet
another remote server for, say, backup transfers.  The connection is
authenticated via ssh auth forwarding back to the lbb while the
acknowledgment script confirms the authentication occurs at the correct
times and the correct number of times during the process (and raises
alarms if something takes place out of step or too many times).  When
the processes are complete, the connections are broken down and the
first server has no way to authenticate to the second server, since it
has no private keying materials present.  No passwords are required,
since the keys are stored on a system to which no remote login is
permitted and which exists behind strict security barriers.  You can
build a complete state machine and engine based on this model using
multiple keys to control highly complex interactions between multiple
remote systems and keep them all secure with NO passwords and NO private
key material present on the external sites and NO password on the
private key on a highly secured staging engine.

Second example...  My laptop incorporates full hard drive (partition)
encryption via LUKS (and has for years).  All of my private keying
material exists only on encrypted drives (or encrypted drive images).
Passwords are merely static encryption on the keys.  But, anyone with
the ability to access those keys when the drives are unlocked (system
running) would have the ability to trojan binaries or otherwise capture
my passwords on those keys.  I am required to have this level of
encryption on my drives now for totally external reasons regardless of
my use of ssh auth keys.  I fail to see any value-add here at all where
other, stronger, encryption prevails and dominates.

In most environments I can envision where you would find this
complicated scheme of insuring strong passwords on keys (even if that
were possible) I would expect, just from a pure regulatory compliance
standpoint, you would first require file system or drive encryption to
protect other valuable private information.  So, either you are not
providing any value add with this additional layer of complexity or you
are leaving other sensitive material exposed.  I'm not sure I'm
comfortable with that decision.

This scheme also fails when you take into account hardware crypto
devices such as smart cards and things like the tpm present on most
decent laptops nowadays.  These these are crypto devices that can store
keys and even generate keys and can lock them in a way that they can not
be retrieved from the device, protected only by a PIN, which is in no
way shape or form going to comply with your idea of a strong password.
Yet, this is vastly superior to a scheme of requiring strong passwords
on ssh keys.  If you are going to this much trouble, buy these people
some OpenPGP smart-keys/smart-cards and save yourself a lot of time,
expense, and headaches.  You'll be more secure and your users will be
one hell of a lot happier with strong security that's actually
convenient and easy to use!  Imagine that.


So...  I'd like to hear more about the requirements for this system
you're working on.  I've seen too many of these systems which are really
designed to make the user's life more difficult but make them "feel
secure" because it's an inconvenience being imposed on them rather than
real security that is transparent and convenient but gains nobody any
accolades and doesn't impress anyone that you're doing something to make
them secure.  A LOT of what I learn is from people in unique situations
I never anticipated with problem requiring unique solutions I had not
considered before.  This sounds like one of them and I'm intrigued.


> -- 
> -- 
> James P. Kinney III
> I would rather stumble along in freedom than walk effortlessly in chains.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20101223/c9cee54c/attachment-0001.bin