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 PeterReceived 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