multiple Host entries in ssh_config

Darren Tucker dtucker at zip.com.au
Wed Sep 28 19:52:06 EST 2005


Vincent.McIntyre at csiro.au wrote:
>>> to clarify, you're saying keywords are first-match-wins-all ?
>> I don't see a difference between that and "first match".
> 
> It's the same thing just a bit more verbose. I like a bit of
> redundancy, this "English" protocol thing can be rather ambiguous...

I just went and compared your patch to the existing text and it doesn't 
seem to add anything that's not already on the previous page.

I'd rather clarify the existing text if needed than add redundancy 
(quoth our fearless leader, "they're manual pages not tea-time 
chit-chats" :-)

Maybe they need an EXAMPLES section, though?

[...]
> Yes, that's the idea. It's confusing at first, that for a given
> destination some elements of the configuration for that session will
> come from one Host "statement group" and some will come from others.
> It's actually a good design, once you get your head around it.
> But difficult to express succinctly, the patch I sent could also
> use a tweak to capture this better.

There's probably a decent demand for some more detailed user-level 
documentation to cover this and things like it in a different style 
(conversational/tutorial, examples, that sort of thing) rather than man 
page style (comprehensive, authoritative, succint).

If someone wants a spare-time project this would probably be a good one. 
  If the quality is good enough then we would probably put it up on 
openssh.com.

There's some good source material around: man pages and FAQ, djm's 
presentation and tutorial[1], Markus' presentation [2] (if you can lesen 
Sie Deutschen :-)

> At the risk of sidetracking you... I don't know if this is a lot of
> work or exists already, but it might be useful to have an option to
> ssh like --config-summary or --show-config that prints the accumulated
> configuration from all the inputs (commandline, $HOME/.ssh/config,
> /etc/ssh/ssh_config, compilation) and exits. "-O" looks to be free...

I like that idea (it would make debugging reported problems easier for 
one thing, since you would not have to guess which options were in 
effect) but I would just add them as debug3's.

[1] http://www.mindrot.org/~djm/auug2002/
[2] http://www.openbsd.org/papers/cebit2003/index.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.




More information about the openssh-unix-dev mailing list