Subject: Re: setuid ssh
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
From: Andrew Brown <atatat@atatdot.net>
List: tech-security
Date: 10/18/2000 09:47:11
  by mail.netbsd.org with SMTP; 18 Oct 2000 13:47:24 -0000
	by noc.untraceable.net (8.11.1/8.11.1/bonk!) id e9IDlCs29652;
	Wed, 18 Oct 2000 09:47:12 -0400 (EDT)
Date: Wed, 18 Oct 2000 09:47:11 -0400
From: Andrew Brown <atatat@atatdot.net>
To: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
Cc: Atsushi Onoe <onoe@sm.sony.co.jp>, cjs@cynic.net,
   hubert.feyrer@informatik.fh-regensburg.de, tech-security@netbsd.org
Subject: Re: setuid ssh
Message-ID: <20001018094711.A29595@noc.untraceable.net>
Reply-To: Andrew Brown <atatat@atatdot.net>
References: <onoe@sm.sony.co.jp> <20001018133849.2EB5C2A2A@orchard.arlington.ma.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20001018133849.2EB5C2A2A@orchard.arlington.ma.us>; from sommerfeld@orchard.arlington.ma.us on Wed, Oct 18, 2000 at 09:38:44AM -0400
Return-Receipt-To: receipts@daemon.org

>> I think .rhosts/rsa configuration may still be suitable for some
>> enviroment; e.g. remote backup from cron.  Perhaps you want to set
>> IgnoreUserKnownHosts.
>
>for backups, you can create a passphraseless trusted key in
>~backup/.ssh and get roughly the same security properties without
>requiring the ssh client to be setuid.

as long as you don't copy that key anywhere.  sure, that key can
*only* be used to log into the backup server, but from *anywhere*.
rhosts says only one account on one machine can log in.  that's the
difference between rhosts and rsa authentication: to spoof rhosts, i'd
have to spoof the ip address of the machine i want to pretend to be.
it's much easier to copy a key.

and wait.  there's another bit of rhosts/rsa authentication that i
failed to consider: it uses the host key, not the user's key.  hrm.

>> I'm afraid that disabling all authentication other than user's RSA
>> causes proliferation of ssh-agent, which looks more halmful than
>> rhosts/rsa authentication.
>
>the difference is that ssh-agent can be turned off when the user is
>not present; this is not the case for .rhosts/rsa.

ssh-agent should be changed anyway.  what it *should* do is store the
decrypted key for a period of time and then expunge it (ala kerberos's
tgt, or sudo), requiring the user to reauthenticate periodically.
once i look more closely at it, i'll have more colorful ideas, i'm
sure.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."