No subject

requiring the user to do anything special.  i.e. when they run "ssh gate -p 22" 
it just works and when they run "ssh gate -p 1022" it just works.  Having to 
tell everyone who will remotely access our system (i.e. employees, contractors, 
customers, etc) that they have to go setup special configurations with special 
options in order to access our network just isn't practical.

The tool is suppose to work for the user, not the other way around.

As for disk space, each line in these files is a little over 200 bytes.  if 
your file system is so tight that you can't put a couple extra KB on your disk, 
you've got bigger problems.

As for the statement that the entries in the known_hosts file are suppose to 
represent "real" ssh servers, that is also not true.  As an IT Manager, I 
explicitly want to control how my network appears to the outside world.  The 
only points of contact (and knowledge) that the outside world has about my 
network are defined through my firewalls.  Everything that the outside world 
knows about my network must be related the defined entry points to my network, 
not the internals of my network.

As for verifying every IP:Port pair, the simple answer is "YES".  Again, since 
every IP:Port pair could map to a completely separate system you actually have 
to verify each IP:Port pair because making the assumption that all ports on a 
particular IP go to a single host is simply wrong.

Tell you what, if I patch up the code and send it to you, will you roll it into 
the next release?



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.