Tom Martin wrote:
> Authentication itself is a very serious security issue.
> No serious security manager would rely on proper timeouts and on proper
> IP routing. There are several possibilities for manipulating this.
> This is exactly the reason why ssl authentication exists.
> I am sure you don't want to say that this feature has no reason.
Yes, but it is the ssh program itself which challenged the user about the
changed key, not Subversion. I'm not even sure that it is possible at the
Subversion level to affect this behavior, since ssh is the secure transport
method and only after the connection is established that svn gets control again.
This feature belongs in ssh, not in Subversion.
In particular, the StrictHostKeyChecking option to .ssh/config seems to be
exactly what you want:
StrictHostKeyChecking
If this flag is set to ``yes'', ssh will never automatically add
host keys to the $HOME/.ssh/known_hosts file, and refuses to con-
nect to hosts whose host key has changed. This provides maximum
protection against trojan horse attacks, however, can be annoying
when the /etc/ssh/ssh_known_hosts file is poorly maintained, or
connections to new hosts are frequently made. This option forces
the user to manually add all new hosts. If this flag is set to
``no'', ssh will automatically add new host keys to the user
known hosts files. If this flag is set to ``ask'', new host keys
will be added to the user known host files only after the user
has confirmed that is what they really want to do, and ssh will
refuse to connect to hosts whose host key has changed. The host
keys of known hosts will be verified automatically in all cases.
The argument must be ``yes'', ``no'' or ``ask''. The default is
``ask''.
Set this to ``yes'' in the .ssh/config file (or if all users are on the same
system, then the systemwide config file), and you won't have to worry about this
again.
John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 21 03:31:13 2004