Re: ~/.hosts patch

From: Peter Ross <Peter.Ross_at_alumni.tu-berlin.de>
Date: Thu, 22 Jun 2006 12:05:58 +1000 (EST)
Hi,

On Wed, 21 Jun 2006, Garance A Drosihn wrote:

> As far as interesting tricks for ssh, you should already
> be able to do that with ~/.ssh/config.  Note ~/.hosts
> would only redirect the hostnames, and not ports.  I use
> ~/.ssh/config so that a plain '_at_host' request actually
> goes to '_at_host:alternate-port', so-to-speak.

Actually I was not aware of this option.

> I have a feeling ~/.hosts could open a few security issues,
> but obviously I am already using ~/.ssh/config to do about
> the same thing on a smaller scale.

It is restricted to one service.

> I also wonder if this would
> trigger some debugging-issues, when some user has long since
> forgotten some alias they put in ~/.hosts, and then some new
> service does not work, and they file a trouble-ticket with
> whoever is providing that service.

Some of the problems popping up again and again are related to shell 
resource files.

E.g. if there is a temporary problem with path variables (e.g. in the 
first stage of implementing a filesystem standard suiting the business 
needs, or if you are in the transition from one operation system to 
another)

you can be sure someone hardcodes the path in his shell resource file. It 
creates trouble if you try systemwide changes later.

Fortunatelly this is already considered by the shell developers. The 
behaviour of an interactive and non-interactive shell (e.g. scripts) 
varies, there are also helpful -norc options if I want to debug problems 

(I was working as a consultant and saw on same client sides very 
complicated resource files to acustomise the login, sometimes invoking a 
menu at the end.. I am not a hugh fan of it but that's reality)

The .hosts file seems to bypass this. And if it is a nsswitch module you 
cannot modify this behaviour for specific commands (e.g. just to enable it 
for an interactive shell). So it is just partly under user control.

You can be sure that one very smart person will add host names into .hosts 
file if you just have a five minute DNS problem.

In the real world badly managed DNS setups, missing reverse lookups etc. 
cause a lot of problems, delays, timeouts (sometimes to a point when you 
are not able to login to fix problems). The .hosts file adds to the 
complexity and I just do not see a hugh gain.

One "myhost=1..2.3.4; export myhost" and the usage of $myhost gives you 
the same value (in most situations) without this, and it easy to spot. I 
can hardly imagine a situation where you really _need_ a .hosts.

If the machine/network setup is screwed I recommend to leave it to a sys 
admin to fix it. And, yes, it also includes test beds where a developer 
would like to point a name to another IP address for testing purposes.

Regards
Peter
Received on Thu Jun 22 2006 - 00:06:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:57 UTC