Robert Watson wrote: > I.e., suppose you distributed a single identity.pub to a number of hosts > as authorized_key to log in. Suppose you make use of ssh-agent, and > ssh-add, to cache the keying material for use. Now suppose one of those > hosts is compromised--for the lifetime of your ssh connection, the cracker > of the compromised host can log into any account on the other hosts using > that authorized_keys. > > If we're switching to a model where X11 forwarding is disabled by default > on the client, we should also consider disabling agent forwarding, which > can present a similar and significant risk. A better and far safer way is to modify ssh-agent so that you have an active local unix domain socket to it or something and have a foreground "monitor" program that is required to manually authorize the use of the agent. I had something hacked up a while back that did just this. It sat in an xterm in a loop and it would beep several times when an authentication request came in via the tunnel and would prompt you for an ack/nak for the request. So, when you used the ssh agent you would get a few beeps and everything would pause while waiting for the ack. Once you OK'ed it, things would continue. The risk is that somebody could wait for you to attempt to use the tunnel and insert a hostile authentication request into the tunnel and you'd ack that instead, but you'd wise up to that pretty quickly when things didn't work or you got a duplicate request or things hung or whatever. By then it may be too late but at least you've been immediately alerted to the problem. I didn't see an easy way to identify the origin of an authentication challenge. It complicated the code somewhat and I was never entirely happy with it. I don't think I've got the code around now, I suspect I hacked it up in one of the FreeBSD ports work areas and later deleted it as part of a mass cleanup. :-( It shouldn't be too hard to duplicate though. Cheers, -Peter
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:38:29 PDT