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.
