[vox-tech] sshd_config and PasswordAuthentication

[Karsten M. Self]

on Fri, Jul 22, 2005 at 03:04:46PM -0700, Micah J. Cowan (micah at cowan.name) wrote:
> On Fri, Jul 22, 2005 at 12:02:41PM -0700, Karsten M. Self wrote:
> > on Fri, Jul 22, 2005 at 10:01:32AM -0500, Jay Strauss (me at heyjay.com) wrote:

> > > I think you are talking about passwordless authentication, 
> > 
> > It's not "passwordless", which is a description of negation.  It is
> > possible to set up accounts and SSH-keys without passwords or
> > passphrases.  Naturally, this is highly insecure.
> 
> A small quibble: Using assymetric key cryptography without passphrases
> is not necessarily insecure. 

Actually, there's another scenario for which this holds, below...

Lack of a passphrase *is* significantly less secure.


> If the private key is secure, then a passphrase is not useful. 

The conclusion requires the premise.

The key must then be secure via shell access, filesystem access *and* by
physical access to all media (you *do* have system backups, correct?).
With a passphrase, even an untrusted root has relatively little
likelihood of access to the key, and physical access / offline data
access is similarly protected against.

> A private key is not really harder to secure than a passphrase is

No, it's much harder to secure.  

A passphrase isn't long-term resident on disk and accessible via
numerous routes.  A passphrase-protected private key is a case of
"something I have + something I know", which works pretty well in
practice.

A private key isn't handed around as a password is.  

Threat model, unsecured private key:

    I trust me, my local host, host, and any hosts I use this password
    on, as well as physical security of local and remote hosts, and
    security of offline backups of local and remote hosts, any password
    storage systems I use, and any inadvertant access to any shell
    with access to the private key.

Threat model, passphrase:

    I trust me, my local host, and any password storage systems I use,
    and any inadvertant access to a shell with access to the private
    key, where that shell has activated the key (via ssh-agent).
    

> and if the private key is accessible to someone, chances are pretty
> good that the passphrase can be as well.

I disagree with that assessment, see threat models above.

> Also, use of a passphrase-encryption on a more-or-less publicly
> available private key means that the "weakest link" in the security
> chain will be the weaker of (1) the assymetric encryption algorithm and
> (2) the symmetric encryption algorithm used to encrypt the private key
> with the passphrase.

...and the inherent guessability of the passphrase (mix of selection and
passphrase length).

My understanding is that 1 & 2 are cryptographically solid.  Which means
that you're protected by the passphrase, and that an unsecured key falls
to the weakest link of physical security of both the system and any data
backups or archives.

 
> Of course, if the private key is truly private, then the passphrase
> does no harm (other than the minor nuisance it presents to the owner),
> and provides an extra level of protection in the case of *accidental*
> compromise of the private key, for the paranoid (a generally good
> trait to possess).
> 
> Nonetheless, it seems to me that calling the use of public-key
> cryptography without passphrases "highly insecure" is a rather harsh
> exaggeration.

It greatly increases the number of avenues to compromise, and creates a
single token (the private key) which if accessed allows direct access.

By contrast, a passphrase-protected key follows the doctrine of
'something I have, something I know", in providing security, and renders
the key by itself largely useless.


Following my own current practices, my risks are:

  - Someone guesses my passphrase.  They can now use the key without
    limit.  The passphrase is long, random, and not stored in cleartext
    anywhere.

  - Someone accesses my system while it's running with ssh-agent
    enabled.  They can now use the key for the duration of that session.

  - Someone knows a cryptographic attack on SSH (none are publicly
    known).  Likelihood of this is low.

Otherwise, opportunities to use my private key without authorization are
pretty slim.


The one exception to an unsecured private key is in the case of a forced
command.  This is a mode of operation in SSH where a specific command is
executed through use of a dedicated public key.  This is useful for such
tasks as unattended backups, rsync triggers, or SSL server initiation.
The risk can be minimized, with an appropriately constructed commande,
to allowing Eve to run your admin tasks for you, with no other
inadvertant program execution or data disclosure.  This isn't an
automatic feature -- you *can* use forced commands to open yourself to
attack.  However with appropriate precautions, it's a case where a
non-passphrase protected key may be used securely.


Peace.

-- 
Karsten M. Self <kmself at ix.netcom.com>        http://kmself.home.netcom.com/
 What Part of "Gestalt" don't you understand?
    The more the merrier.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://ns1.livepenguin.com/pipermail/vox-tech/attachments/20050722/86d0c654/attachment.pgp