Security suggestion concering SSH and port forwarding.

[Carson Gaspar]

--On Monday, January 19, 2004 5:04 PM -0600 Ben Lindstrom 
<mouring at etoh.eviladmin.org> wrote:

> People pick shitty system passwords also.  Your point?  As SSH clients are
> integrated into ftp cleints, OS etc, more and more of those shitty
> passwords are "stored" clear text or cheaply scrambled method.  All so the
> user does not have to reenter it day in and day out.

I can't stop my users from storing passphrases. I can force them to pick 
good ones, and to change them on a regular basis. Having done both, this 
_does_ lead to better user behaviour than pubkey auth. Of course, back when 
I ran this sort of thing, I did both - they had to authenticate with a 
public key (where thay control the ease of use / security), and then 
authenticate with a passphrase (where I did). If I really felt like it, I 
could detect users who stored the passphrase by looking at the timing 
(assuming lazy and not malicious users). If you want better security than 
that, you need to go to hardware tokens / smartcards / whatever, and accept 
the costs.

>> Which makes me think... if I extended the authorized key mechanisms to
>> match against a username instead of (or in addition to, if
>> applicable...) a key, is there a chance that would get merged in? The
>> current functionality is pretty good, but only if you use pubkey auth.
>> It would be nice to get the same functionality regardless of auth
>> mechanism.
>>
>
> Not sure I see a point.  How does this improve anything?

It allows the same nice user behaviour controls (port forwarding, only run 
this command, etc.) even if we choose not to use public key auth.

-- 
Carson