Connection caching?

[Jefferson Ogata]

Damien Miller wrote:
> Jefferson Ogata wrote:
>>It's hard enough to keep lazy users from eliminating any challenge from 
>>normal pubkey authentication by using ssh-agent or unpassphrased private 
>>keys. But there are ways to force clients to be intelligent for 
>>authentication. It's a different ball of wax once you start allowing a 
>>single authentication phase provide a perpetual stream of sessions.
> 
> Like I said: the control socket would be subject to similar checks that
> we perform for other sockets (e.g. ssh-agent). I.e it must live in a
> secure directory and we can enforce getpeerid checks to ensure that
> it is the same user connecting each time.

Um, I feel like you're missing the point. I can prevent users from using 
ssh-agent by not providing the binary and by not giving them write access to any 
exec filesystem. I can also require authentication mechanisms on the server side 
that ssh-agent cannot answer, e.g. one-time passwords. The mechanism under 
discussion is not amenable to any of these controls. Once someone authenticates 
once, if that user's remote session is compromised, the intruder can piggyback 
over any established ssh connection and there is absolutely no way I can force 
the intruder to authenticate. Do you understand? You're advocating a mechanism 
that renders one-time passwords useless against a remote client compromise. 
That's fine for you, but not for me: I need to be able to turn that off on the 
ssh server.

> I suppose we could also optionally do explicit confirmation via
> ssh-askpass, like we do with ssh-add's -c option.

I don't understand. What would we ask for with ssh-askpass?

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>