Mailing List Archive

[PATCH] Allow matching HostName against Host entries
It would be useful to allow matching HostName entries against Host
entries. That's to say, I would find it very convenient to have an
ssh_config like:

Host zeus
HostName zeus.greek.gods
User hades
Host hera
HostName hera.greek.gods
# [ ... ]
Host *.greek.gods
User poseidon
UserKnownHostsFile ~/.ssh/known_hosts.d/athens
# [ Default settings for *.greek.gods ]

where I can then go
$ ssh zeus
to log in as hades on zeus.greek.gods, using the settings in the stanzas
matching zeus and zeus.greek.gods. Similarly,
$ ssh hera
to log on as poseidon on hera.greek.gods, using the settings in the
stanzas matching hera and hera.greek.gods. This allows me to set an
"alias" for frequently hosts while still using the settings matching the
associated HostName.

This is similar to writing

Host zeus
HostName zeus.greek.gods
User hades
Host hera
HostName hera.greek.gods
# [ ... ]
Host *.greek.gods zeus hera [ ... ]
User poseidon
UserKnownHostsFile ~/.ssh/known_hosts.d/athens
# [ Default settings for *.greek.gods ]

making use of the "fallthrough" functionality of ssh's config parser,
where each Host stanza matching the name given on the command line is
parsed, setting any parameters not previously set. Unfortunately, this
becomes unmanageable for large numbers of "aliases".

Now said functionality might break existing SSH configs, and some users
might find it undesirable, so I've added the following ssh_config
parameter:

MatchHostName
This option matches the value of HostName against any
subsequent Host entries. MatchHostName may be set at any
point, but only takes effect once HostName is set. The
argument to this keyword must be ``yes'' or ``no''. The
default is ``no''.

Please see the patch below for the details. I wasn't able to get SSH to
build on a CVS checkout of OpenBSD-current (with or without the patch),
but it applied, compiled, and ran fine on my CVS checkout of OpenBSD
5.2.

Best wishes,
Ryan

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A

Index: usr.bin/ssh/ssh_config.5
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v
retrieving revision 1.161
diff -u -r1.161 ssh_config.5
--- usr.bin/ssh/ssh_config.5 8 Jan 2013 18:49:04 -0000 1.161
+++ usr.bin/ssh/ssh_config.5 22 Mar 2013 01:34:26 -0000
@@ -810,6 +810,22 @@
hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,
hmac-sha1-96,hmac-md5-96
.Ed
+.It Cm MatchHostName
+This option matches the value of
+.Cm HostName
+against any subsequent
+.Cm Host
+entries.
+.Cm MatchHostName
+may be set at any point, but only takes effect once
+.Cm HostName
+is set.
+The argument to this keyword must be
+.Dq yes
+or
+.Dq no .
+The default is
+.Dq no .
.It Cm NoHostAuthenticationForLocalhost
This option can be used if the home directory is shared across machines.
In this case localhost will refer to a different machine on each of
Index: usr.bin/ssh/readconf.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
retrieving revision 1.197
diff -u -r1.197 readconf.c
--- usr.bin/ssh/readconf.c 6 Mar 2013 23:36:53 -0000 1.197
+++ usr.bin/ssh/readconf.c 22 Mar 2013 01:34:26 -0000
@@ -128,7 +128,7 @@
oAddressFamily, oGssAuthentication, oGssDelegateCreds,
oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
oSendEnv, oControlPath, oControlMaster, oControlPersist,
- oHashKnownHosts,
+ oHashKnownHosts, oMatchHostName,
oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication,
oKexAlgorithms, oIPQoS, oRequestTTY,
@@ -228,6 +228,7 @@
{ "controlmaster", oControlMaster },
{ "controlpersist", oControlPersist },
{ "hashknownhosts", oHashKnownHosts },
+ { "matchhostname", oMatchHostName },
{ "tunnel", oTunnel },
{ "tunneldevice", oTunnelDevice },
{ "localcommand", oLocalCommand },
@@ -823,7 +824,9 @@
negated = *arg == '!';
if (negated)
arg++;
- if (match_pattern(host, arg)) {
+ if (match_pattern(host, arg) ||
+ (options->match_host_name == 1 && &options->hostname != NULL &&
+ match_pattern(options->hostname, arg))) {
if (negated) {
debug("%.200s line %d: Skipping Host "
"block because of negated match "
@@ -970,6 +973,10 @@
intptr = &options->hash_known_hosts;
goto parse_flag;

+ case oMatchHostName:
+ intptr = &options->match_host_name;
+ goto parse_flag;
+
case oTunnel:
intptr = &options->tun_open;
arg = strdelim(&s);
@@ -1207,6 +1214,7 @@
options->control_persist = -1;
options->control_persist_timeout = 0;
options->hash_known_hosts = -1;
+ options->match_host_name = -1;
options->tun_open = -1;
options->tun_local = -1;
options->tun_remote = -1;
@@ -1345,6 +1353,8 @@
}
if (options->hash_known_hosts == -1)
options->hash_known_hosts = 0;
+ if (options->match_host_name == -1)
+ options->match_host_name = 0;
if (options->tun_open == -1)
options->tun_open = SSH_TUNMODE_NO;
if (options->tun_local == -1)
Index: usr.bin/ssh/readconf.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/readconf.h,v
retrieving revision 1.93
diff -u -r1.93 readconf.h
--- usr.bin/ssh/readconf.h 22 Feb 2013 04:45:09 -0000 1.93
+++ usr.bin/ssh/readconf.h 22 Mar 2013 01:34:26 -0000
@@ -125,6 +125,8 @@

int hash_known_hosts;

+ int match_host_name;
+
int tun_open; /* tun(4) */
int tun_local; /* force tun device (optional) */
int tun_remote; /* force tun device (optional) */
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
Hi,

I really think this patch[0] would be useful to users[1] and would be nice
to have incorporated. Was this the correct list to submit it to, or
should I have sent it to tech@openbsd.org or elsewhere? Is there
anything I can do to help it get included?

Best wishes,
Ryan

[0] http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-March/031166.html
[1] See for example
http://superuser.com/questions/469329/ssh-config-wildcard-on-expanded-hostname
http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026829.html

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Apr 8, 2013, at 11:25 AM, Ryan Kavanagh <rak@debian.org> wrote:

> Hi,
>
> I really think this patch[0] would be useful to users[1] and would be nice
> to have incorporated. Was this the correct list to submit it to, or
> should I have sent it to tech@openbsd.org or elsewhere? Is there
> anything I can do to help it get included?


Isn't this failure to understand that the Host list is in first match order? So place
what you wish to have highest priority first, and then the remaining wildcard
matches towards the bottom.

I've been doing this for ages without needing yet another option. Unless your
description isn't fully explaining why we need this option.

- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
Hi Ben,

On Monday, April 8, 2013 at 13:13:38 -0500, Ben Lindstrom wrote:
> Isn't this failure to understand that the Host list is in first
> match order? So place what you wish to have highest priority first,
> and then the remaining wildcard matches towards the bottom.

Far from it, this patch helps users make use of the fact that the Host
list is in first match order. Very briefly put, what it lets you do is
have ssh also try to match the first HostName entry from a matching
Host stanza against any subsequent Host stanzas. Without this patch,
if you had a stanza like

Host myhost
HostName myhost.foo.bar

the command "ssh myhost" would not have ssh match against the stanza

Host *.foo.bar
Foo1 Bar1

You could argue that I could just setup the "search" option in
resolv.conf. But what if I have hosts outside of my local domain, or
my administrator doesn't give me edit writes to /etc/resolv.conf? You
could also argue that I could change this wildcard to

Host *.foo.bar myhost
Foo1 Bar1

but this quickly becomes unmanageable with complex config files, as my
example below shows.

> I've been doing this for ages without needing yet another option.
> Unless your description isn't fully explaining why we need this
> option.

Maybe my example wasn't clear. Imagine you have 510 boxes split across
two networks; 255 are in a student lab, and the remaining 255 are in a
professor lab. Let's make things dramatic and imagine you have
settings for each one of these machines, and settings for each lab,
and settings for both labs. You want to have an alias for each host,
for example, you want to be able to go "ssh slab1" to connect to
"lab1.student.lab" (for the sake of simplicity, I've just numbered
things and one could just use a "slab*" wildcard, but let's keep in
mind cases where this wouldn't work). Under the current ssh_config,
you'd have something that looked like:

#### BEGIN CURRENT SSH_CONFIG ####
VisualHostKey yes

Host slab1
User slab1
HostName lab1.student.lab

## Repeat for slab{2..254}

Host slab255
User slab255
Hostname lab255.student.lab

Host plab1
User plab1
HostName lab1.professor.lab

## plab{2..254}

Host plab255
User plab255
HostName lab255.professor.lab

# Insert whatever other hosts you know of

Host *.student.lab slab1 slab2 ... slab255
IdentityFile ~/.ssh/id_ecdsa.slab
UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab

Host *.professor.lab plab1 plab2 ... plab255
IdentityFile ~/.ssh/id_ecdsa.plab
UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab

Host *.lab slab1 slab2 ... slab255 plab1 plab2 ... plab255
VisualHostKey no
ForwardX11 yes
#### END CURRENT SSH_CONFIG ####

Note that the Host lines matching each lab will be 256 entries long,
and the one matching both labs will be 511 entries long. Now imagine
being able to match the corresponding HostName entry against a
wildcard. With my patch, your config would look like:

#### BEGIN PROPOSED SSH_CONFIG ####
MatchHostName yes
# ^^^^ This is the magic line
VisualHostKey yes

Host slab1
User slab1
HostName lab1.student.lab

## Repeat for slab{2..254}

Host slab255
User slab255
Hostname lab255.student.lab

Host plab1
User plab1
HostName lab1.professor.lab

## plab{2..254}

Host plab255
User plab255
HostName lab255.professor.lab

# Insert whatever other hosts you know of

Host *.student.lab
IdentityFile ~/.ssh/id_ecdsa.slab
UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab

Host *.professor.lab
IdentityFile ~/.ssh/id_ecdsa.plab
UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab

Host *.lab
VisualHostKey no
ForwardX11 yes
#### END PROPOSED SSH_CONFIG ####

In my opinion, this proposed ssh_config is considerably cleaner, and
easier to understand and manage. My own interest in this patch is
similar. I have a couple dozen hosts I connect to across three
domains. I'd like to be able to connect to each of these by using the
subdomain (set with HostName in a Host stanza matching the subdomain),
while still having the domain wildcard matched.

As for implementation, the "MatchHostName yes" doesn't need to be
enabled globally as in the example above. It can be used only for
certain aliases. Moreover, my patch only takes effect once there's
been a HostName entry in a matching Host stanza and MatchHostName has
been enabled.

I hope this helps, please let me know if you have any questions,
concerns, or comments.

Best wishes,
Ryan

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Mon, Apr 08, 2013 at 20:09:41 -0500, Ryan Kavanagh wrote:
> Hi Ben,
>
> On Monday, April 8, 2013 at 13:13:38 -0500, Ben Lindstrom wrote:
> > Isn't this failure to understand that the Host list is in first
> > match order? So place what you wish to have highest priority first,
> > and then the remaining wildcard matches towards the bottom.
>
> Far from it, this patch helps users make use of the fact that the Host
> list is in first match order. Very briefly put, what it lets you do is
> have ssh also try to match the first HostName entry from a matching
> Host stanza against any subsequent Host stanzas. Without this patch,
> if you had a stanza like
>
> Host myhost
> HostName myhost.foo.bar
>
> the command "ssh myhost" would not have ssh match against the stanza
>
> Host *.foo.bar
> Foo1 Bar1
>
> You could argue that I could just setup the "search" option in
> resolv.conf. But what if I have hosts outside of my local domain, or
> my administrator doesn't give me edit writes to /etc/resolv.conf? You
> could also argue that I could change this wildcard to
>
> Host *.foo.bar myhost
> Foo1 Bar1
>
> but this quickly becomes unmanageable with complex config files, as my
> example below shows.
>
> > I've been doing this for ages without needing yet another option.
> > Unless your description isn't fully explaining why we need this
> > option.
>
> Maybe my example wasn't clear. Imagine you have 510 boxes split across
> two networks; 255 are in a student lab, and the remaining 255 are in a
> professor lab. Let's make things dramatic and imagine you have
> settings for each one of these machines, and settings for each lab,
> and settings for both labs. You want to have an alias for each host,
> for example, you want to be able to go "ssh slab1" to connect to
> "lab1.student.lab" (for the sake of simplicity, I've just numbered
> things and one could just use a "slab*" wildcard, but let's keep in
> mind cases where this wouldn't work). Under the current ssh_config,
> you'd have something that looked like:
>
> #### BEGIN CURRENT SSH_CONFIG ####
> VisualHostKey yes
>
> Host slab1
> User slab1
> HostName lab1.student.lab
>
> ## Repeat for slab{2..254}
>
> Host slab255
> User slab255
> Hostname lab255.student.lab
>
> Host plab1
> User plab1
> HostName lab1.professor.lab
>
> ## plab{2..254}
>
> Host plab255
> User plab255
> HostName lab255.professor.lab
>
> # Insert whatever other hosts you know of
>
> Host *.student.lab slab1 slab2 ... slab255
> IdentityFile ~/.ssh/id_ecdsa.slab
> UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab
>
> Host *.professor.lab plab1 plab2 ... plab255
> IdentityFile ~/.ssh/id_ecdsa.plab
> UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab
>
> Host *.lab slab1 slab2 ... slab255 plab1 plab2 ... plab255
> VisualHostKey no
> ForwardX11 yes
> #### END CURRENT SSH_CONFIG ####
>
> Note that the Host lines matching each lab will be 256 entries long,
> and the one matching both labs will be 511 entries long. Now imagine
> being able to match the corresponding HostName entry against a
> wildcard. With my patch, your config would look like:
>
> #### BEGIN PROPOSED SSH_CONFIG ####
> MatchHostName yes
> # ^^^^ This is the magic line
> VisualHostKey yes
>
> Host slab1
> User slab1
> HostName lab1.student.lab
>
> ## Repeat for slab{2..254}
>
> Host slab255
> User slab255
> Hostname lab255.student.lab
>
> Host plab1
> User plab1
> HostName lab1.professor.lab
>
> ## plab{2..254}
>
> Host plab255
> User plab255
> HostName lab255.professor.lab
>
> # Insert whatever other hosts you know of
>
> Host *.student.lab
> IdentityFile ~/.ssh/id_ecdsa.slab
> UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab
>
> Host *.professor.lab
> IdentityFile ~/.ssh/id_ecdsa.plab
> UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab
>
> Host *.lab
> VisualHostKey no
> ForwardX11 yes
> #### END PROPOSED SSH_CONFIG ####
>
> In my opinion, this proposed ssh_config is considerably cleaner, and
> easier to understand and manage. My own interest in this patch is
> similar. I have a couple dozen hosts I connect to across three
> domains. I'd like to be able to connect to each of these by using the
> subdomain (set with HostName in a Host stanza matching the subdomain),
> while still having the domain wildcard matched.
>
> As for implementation, the "MatchHostName yes" doesn't need to be
> enabled globally as in the example above. It can be used only for
> certain aliases. Moreover, my patch only takes effect once there's
> been a HostName entry in a matching Host stanza and MatchHostName has
> been enabled.
>
> I hope this helps, please let me know if you have any questions,
> concerns, or comments.
>

As you imply above, this could be addressed by using a consistent scheme
for your aliaes. Thus, the latter portions of your configuration could
use globbing:

Host *.student.lab slab*
...

Host *.professor.lab plab*
...

Host *.lab plab* slab*
...

Another approach which could address similar issues would be support for
subnet configuration, as requested in bz#1169[1].

--
Iain Morgan

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=1169
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
Hi Iain,

On Tuesday, April 9, 2013 at 12:00:43 -0700, Iain Morgan wrote:
> As you imply above, this could be addressed by using a consistent scheme
> for your aliaes.

That is true, but ignores the fact that this is not always
possible. Some organisations don't numerically number their hosts and
instead name them after Greek gods, after composers, or
arbitrarily. And so one resorts to the consistent scheme of
"hostname.domain.tld" -> "hostname". For a simple example, consider my
config file with the patch[0], without the patch[1], and the diff[2].

As far as I can tell from looking through the patch, it won't break
any existing configuration files, and will only serve to simplify
those making use of it.

Best wishes,
Ryan

[0] http://people.debian.org/~rak/ssh_configs/config.new
[1] http://people.debian.org/~rak/ssh_configs/config.old
[2] http://people.debian.org/~rak/ssh_configs/config.diff

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Apr 9, 2013, at 2:57 PM, Ryan Kavanagh <rak@debian.org> wrote:

> Hi Iain,
>
> On Tuesday, April 9, 2013 at 12:00:43 -0700, Iain Morgan wrote:
>> As you imply above, this could be addressed by using a consistent scheme
>> for your aliaes.
>
> That is true, but ignores the fact that this is not always
> possible. Some organisations don't numerically number their hosts and
> instead name them after Greek gods, after composers, or
> arbitrarily. And so one resorts to the consistent scheme of
> "hostname.domain.tld" -> "hostname". For a simple example, consider my
> config file with the patch[0], without the patch[1], and the diff[2].
>
> As far as I can tell from looking through the patch, it won't break
> any existing configuration files, and will only serve to simplify
> those making use of it.

My major complaint is this one option changes how the ssh_config is
parsed. It just takes one admin to decided he likes it to break everyone's
setup..

e.g.

host foo
user specialaccount
hostname foo.bar.com

host *.bar.com
user normaluser


Which is horrible as it *DOES* break it if you enable that switch.

- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Tue, Apr 09, 2013 at 14:57:13 -0500, Ryan Kavanagh wrote:
> Hi Iain,
>
> On Tuesday, April 9, 2013 at 12:00:43 -0700, Iain Morgan wrote:
> > As you imply above, this could be addressed by using a consistent scheme
> > for your aliaes.
>
> That is true, but ignores the fact that this is not always
> possible. Some organisations don't numerically number their hosts and
> instead name them after Greek gods, after composers, or
> arbitrarily. And so one resorts to the consistent scheme of
> "hostname.domain.tld" -> "hostname". For a simple example, consider my
> config file with the patch[0], without the patch[1], and the diff[2].

While it helps if the hostnames follow a consistent naming scheme, it is
not strictly necessary. Since you have control of the aliases which you
introduce in your ~/.ssh/config, you can apply whatever scheme is
convenient. For example, if a system's hostname is "zeus" you could use
"Host slab-zeus" in your configuration. Admittedly, this does require
that you remember to use the naming scheme which you have imposed
whenever you ssh to one of these systems.

--
Iain Morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Tuesday, April 9, 2013 at 15:06:55 -0500, Ben Lindstrom wrote:
> My major complaint is this one option changes how the ssh_config is
> parsed. It just takes one admin to decided he likes it to break everyone's
> setup..
>
> e.g.
>
> host foo
> user specialaccount
> hostname foo.bar.com
>
> host *.bar.com
> user normaluser
>
> Which is horrible as it *DOES* break it if you enable that switch.

I'm not sure I follow your counterexample. Even if the switch was
enabled, "ssh foo" would still use "user specialaccount", not "user
normaluser" since the switch doesn't break the first match
order. Nowhere does the patch affect the check on lines 397 or 414[0]
that only set an option if it hasn't yet been unset. Or am I
misunderstanding something? Now, assume that your counterexample was
instead

## User ~/.ssh/config ##
host foo
user specialaccount
hostname foo.bar.com

## System /etc/ssh/ssh_config
MatchHostName yes

host *.bar.com
user normaluser
ForwardAgent yes

Enabling the proposed switch would in fact cause breakage: agent
forwarding would be enabled for "ssh foo" with the switch on, and
would be the default value with the switch off. I consider this
particular objection to be moot: any changes to the system config file
is prone to breaking users config files or causing severe carnage and
should be done with utmost caution. A nutcase admin can equally well
break everyone's config (and wipe home directories) without needing
any new flags with:

## System /etc/ssh/ssh_config
## Don't try this at home (or work!)
host *
ForwardAgent yes
LocalCommand rm -fr %d
PermitLocalCommand yes

Best wishes,
Ryan

[0] if (*activep && *intptr == -1)
/* *intptr is the pointer to &options->CURRENT_SETTING */
*intptr = value;
--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
I'm not sure if I like it....
I don't think it's that useful....


Am 08.04.2013 um 18:25 schrieb Ryan Kavanagh <rak@debian.org>:

> Hi,
>
> I really think this patch[0] would be useful to users[1] and would be nice
> to have incorporated. Was this the correct list to submit it to, or
> should I have sent it to tech@openbsd.org or elsewhere? Is there
> anything I can do to help it get included?
>
> Best wishes,
> Ryan
>
> [0] http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-March/031166.html
> [1] See for example
> http://superuser.com/questions/469329/ssh-config-wildcard-on-expanded-hostname
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026829.html
>
> --
> |_)|_/ Ryan Kavanagh | Debian Developer
> | \| \ http://ryanak.ca/ | GPG Key 4A11C97A
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
I would find the proposed MatchHostName feature very useful. It
would allow me to remove a significant amount of duplication from
my ssh config files.

On Tue, 09 Apr 2013, Ben Lindstrom wrote:
>My major complaint is this one option changes how the ssh_config is
>parsed. It just takes one admin to decided he likes it to break everyone's
>setup..

Sure. The admin should not put "MatchHostname yes" in the system ssh
config file; it's something that users should be able to choose to put
in their own config files.

>e.g.
>
>host foo
> user specialaccount
> hostname foo.bar.com
>
>host *.bar.com
> user normaluser
>
>Which is horrible as it *DOES* break it if you enable that switch.

You could always override with "MatchHostName no", like this:

MatchHostName yes # global setting

host foo
user specialaccount
hostname foo.bar.com
MatchHostName no # override for "host foo"

host *.bar.com
user normaluser
SomeOtherSetting "used for 'foo.bar.com', but not used for 'foo'"

--apb (Alan Barrett)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Thu, Apr 11, 2013 at 00:06:06 -0500, Alan Barrett wrote:
>
> You could always override with "MatchHostName no", like this:
>
> MatchHostName yes # global setting
>
> host foo
> user specialaccount
> hostname foo.bar.com
> MatchHostName no # override for "host foo"
>
> host *.bar.com
> user normaluser
> SomeOtherSetting "used for 'foo.bar.com', but not used for 'foo'"
>

The example ignores how ssh(1) parses the config file. Since the first
match is applied, global options as shown above cannot be overridden.

--
Iain Morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
You would probably meant something along the lines of:

host foo
user specialaccount
hostname foo.bar.com
MatchHostName no # override for "host foo"

host *.bar.com
user normaluser
SomeOtherSetting "used for 'foo.bar.com', but not used for 'foo'"

host *
MatchHostName no # global setting

in your user config, which would make sure that none of your Host
stanzas match a global config in case your sysadmin decides to turn
the flag on. Of course, if you're depending on you sysadmin's global
config for things, and he changes it to require matchhostname, then
you're equally in trouble. But again, anything your sysadmin does can
break your own configs or worse.

Best wishes,
Ryan

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Wed, 10 Apr 2013, Markus Friedl wrote:

> I'm not sure if I like it....
> I don't think it's that useful....

I can see why someone might want something like it for one particular reason:
we don't do a fantastic job with unqualified hostnames right now. E.g. my
resolv.conf might contain something like:

search mel.int.spectre.com int.spectre.com spectre.com

.. and I run "ssh www023". Without explicit configuration, I'd end up with
an unqualified name in my known_hosts that isn't deduplicated with a
partially, or fully qualified one that might also be in there or come later.

Furthermore, this makes hostkey certificates much less useful. When creating
the certificates I have to chose whether to list only the FQDNs of a host
as principals or whether I should also include unqualified names too. If
I chose FQDNs that my certificates will not authenticate the host if I've
connected using an unqualified name. If I chose to list un- and partially-
qualified names then I open myself to host impersonation attacks (e.g.
consider a certificate for a server named "www" or "proxy").

Much of the pain will go away if we have some option to allow
ssh to canonicalise its hostnames. I thought we could do it using the
AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
users on DHCP networks to new attacks as a spoofed DHCP server can
control the DNS search order.

A better option might be to allow specification of the suffix order in
ssh_config itself. E.g.

HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com

to make ssh try resolution of unqualified names by appending each suffix
in turn and stopping at the first successful lookup. The fully-qualified
result would then replace the unqualified hostname for the purpose of
ssh_config matching, known_hosts lookups and certificate name verification.

What do you think?

-d

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Fri, 12 Apr 2013, Damien Miller wrote:

> Much of the pain will go away if we have some option to allow
> ssh to canonicalise its hostnames. I thought we could do it using the
> AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
> users on DHCP networks to new attacks as a spoofed DHCP server can
> control the DNS search order.

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=getaddrinfo&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Apr 11, 2013, at 9:50 PM, Damien Miller <djm@mindrot.org> wrote:

[..]
> A better option might be to allow specification of the suffix order in
> ssh_config itself. E.g.
>
> HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com
>
> to make ssh try resolution of unqualified names by appending each suffix
> in turn and stopping at the first successful lookup. The fully-qualified
> result would then replace the unqualified hostname for the purpose of
> ssh_config matching, known_hosts lookups and certificate name verification.
>
> What do you think?

Is there no way to pull this information from the resolv.conf file in an universal
way? It really would suck having yet another location for DNS search paths
to maintain an environment.

And out of interest what would your intent be for those names who still fail this
qualification test?

e.g.

## Where minecraft "host" is really a fast alias to set username, an other
## information to correctly log into generic.server.com without having to
## hand specific them all the time.
Host minecraft
User minecraft
Hostname generic.server.com


- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Thu, Apr 11, 2013 at 21:50:54 -0500, Damien Miller wrote:
> On Wed, 10 Apr 2013, Markus Friedl wrote:
>
> > I'm not sure if I like it....
> > I don't think it's that useful....
>
> I can see why someone might want something like it for one particular reason:
> we don't do a fantastic job with unqualified hostnames right now. E.g. my
> resolv.conf might contain something like:
>
> search mel.int.spectre.com int.spectre.com spectre.com
>
> .. and I run "ssh www023". Without explicit configuration, I'd end up with
> an unqualified name in my known_hosts that isn't deduplicated with a
> partially, or fully qualified one that might also be in there or come later.
>
> Furthermore, this makes hostkey certificates much less useful. When creating
> the certificates I have to chose whether to list only the FQDNs of a host
> as principals or whether I should also include unqualified names too. If
> I chose FQDNs that my certificates will not authenticate the host if I've
> connected using an unqualified name. If I chose to list un- and partially-
> qualified names then I open myself to host impersonation attacks (e.g.
> consider a certificate for a server named "www" or "proxy").
>
> Much of the pain will go away if we have some option to allow
> ssh to canonicalise its hostnames. I thought we could do it using the
> AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
> users on DHCP networks to new attacks as a spoofed DHCP server can
> control the DNS search order.
>
> A better option might be to allow specification of the suffix order in
> ssh_config itself. E.g.
>
> HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com
>
> to make ssh try resolution of unqualified names by appending each suffix
> in turn and stopping at the first successful lookup. The fully-qualified
> result would then replace the unqualified hostname for the purpose of
> ssh_config matching, known_hosts lookups and certificate name verification.
>
> What do you think?
>
> -d
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The idea sounds interesting, and would address a variety of issues. I'm
a little concerned about "replacing" the unqualified name: Users could
be confronted by StrictHostkeyChecking messages despite the fact that
they have an entry for the unqualified name in their known_hosts files
and used the unqualified name. We would probably still need to match
against the unqualified name, but give preferrence to the FQDN.

It could also cause some consternation if users place the
HostnameSuffixes option at the beginning of their .ssh/config files;
matches against the unqualified name would then fail. This could be
avoided by using the option in a Host * section near the end of the
file, but I expect a lot of people would have to learn the hard way.

On a side note, this might have implications for bz#1169. Since we would
be resolving the hostname earlier, we would also get the IP address of
the target host and thus could apply options based upon that.

--
Iain Morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Fri, 12 Apr 2013, Ben Lindstrom wrote:

>
> Is there no way to pull this information from the resolv.conf file in
> an universal way? It really would suck having yet another location for
> DNS search paths to maintain an environment.

Pulling it from resolv.conf permits attacks from a rogue/hostile DHCP
server again. The main attack here is host subsitution, if a user happens
to have multiple servers with the same hostname but different domains names
(e.g. "www.good.com" and "www.evil.com") then someone who can spoof the
suffix order could trick a ssh client that used it for canonicalisation
to make a user connect to the wrong host completely transparently.

It's an unlikely scenario for users on small networks, but in a large
organisation with multiple subdomains it could be a useful trick for
an attacker who wants to widen the set of hosts they have compromised.

> And out of interest what would your intent be for those names who
> still fail this qualification test?

They would fall back to regular resolution.

> ## Where minecraft "host" is really a fast alias to set username, an other
> ## information to correctly log into generic.server.com without having to
> ## hand specific them all the time.
> Host minecraft
> User minecraft
> Hostname generic.server.com

So you could do something like:

Host minecraft
User minecraft
Hostname generic.server.com

HostnameSuffixes foo.com ext.foo.com

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Fri, Apr 12, 2013 at 19:06:50 -0500, Damien Miller wrote:
> On Fri, 12 Apr 2013, Ben Lindstrom wrote:
>
> >
> > Is there no way to pull this information from the resolv.conf file in
> > an universal way? It really would suck having yet another location for
> > DNS search paths to maintain an environment.
>
> Pulling it from resolv.conf permits attacks from a rogue/hostile DHCP
> server again. The main attack here is host subsitution, if a user happens
> to have multiple servers with the same hostname but different domains names
> (e.g. "www.good.com" and "www.evil.com") then someone who can spoof the
> suffix order could trick a ssh client that used it for canonicalisation
> to make a user connect to the wrong host completely transparently.
>
> It's an unlikely scenario for users on small networks, but in a large
> organisation with multiple subdomains it could be a useful trick for
> an attacker who wants to widen the set of hosts they have compromised.
>
> > And out of interest what would your intent be for those names who
> > still fail this qualification test?
>
> They would fall back to regular resolution.
>
> > ## Where minecraft "host" is really a fast alias to set username, an other
> > ## information to correctly log into generic.server.com without having to
> > ## hand specific them all the time.
> > Host minecraft
> > User minecraft
> > Hostname generic.server.com
>
> So you could do something like:
>
> Host minecraft
> User minecraft
> Hostname generic.server.com
>
> HostnameSuffixes foo.com ext.foo.com
>

I think you meant:

Host minecraft
User minecraft
Hostname generic.server.com

Host *
HostnameSuffixes foo.com ext.foo.com
--
Iain Morgan
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On 11/04/13 07:06, Alan Barrett wrote:
> I would find the proposed MatchHostName feature very useful. It would
> allow me to remove a significant amount of duplication from my ssh
> config files.
>
> On Tue, 09 Apr 2013, Ben Lindstrom wrote:
>> My major complaint is this one option changes how the ssh_config is
>> parsed. It just takes one admin to decided he likes it to break
>> everyone's
>> setup..
>
> Sure. The admin should not put "MatchHostname yes" in the system ssh
> config file; it's something that users should be able to choose to put
> in their own config files.
>
>> e.g.
>>
>> host foo
>> user specialaccount
>> hostname foo.bar.com
>>
>> host *.bar.com
>> user normaluser
>>
>> Which is horrible as it *DOES* break it if you enable that switch.
What about changing the name of the ‘hostname’ option?

So you would replace hostname above with eg. ‘expandhost’
host foo
expandhost foo.bar.com

The configuration option expandhost would work just like hostname, but
making foo.bar.com match with the following configuration entries.

As it's a new setting, old config files won't be affected like
MatchHostname if the boolean field is enabled (globally or locally
without realising the semantic change for some later entry).

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Fri, 12 Apr 2013, Damien Miller wrote:
>A better option might be to allow specification of the suffix order in
>ssh_config itself. E.g.
>
>HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com

That would help in many cases, but not in all cases.

I have aliases in ssh.conf that do not resemble the FQDN of the
host (e.g. "dev" => "server123.department.company.tld"). Even if
they do match the first label of the FQDN, I might prefer explicit
configuration to some kind of HostnameSuffixes search.

I want something that will significantly reduce the amount of
duplication in configurations like this:

Host dev
HostName server123.dept.company.tld
HostKeyAlias server123.dept.company.tld
UserName U34567
IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
# maybe more options duplicated here

Host test
HostName server475.dept.company.tld
HostKeyAlias server475.dept.company.tld
UserName U34567
IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
# maybe more options duplicated here

Host prod
HostName server931.dept.company.tld
HostKeyAlias server931.dept.company.tld
UserName U34567
IdentityFile "~/.ssh/keys/key-for-production-servers"
# maybe more options duplicated here

Host server931.dept.company.tld
IdentityFile "~/.ssh/keys/key-for-production-servers"

Host *.dept.company.tld
UserName U34567
IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
# maybe more options specified here

"MatchHostName yes" would work fine for me, but I might prefer
different syntax, like the "ExpandHostName" idea that was
suggested in another sub-thread. Then I could replace the above
configuration with this:

Host dev
ExpandHostName server123.dept.company.tld

Host test
ExpandHostName server475.dept.company.tld

Host prod
ExpandHostName server931.dept.company.tld

Host server931.dept.company.tld
IdentityFile "~/.ssh/keys/key-for-production-servers"

Host *.dept.company.tld
UserName U34567
IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
# maybe more options specified here

--apb (Alan Barrett)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Thu, 11 Apr 2013, Ryan Kavanagh wrote:
>You would probably meant something along the lines of:
> [...]
>But again, anything your sysadmin does can
>break your own configs or worse.

Yes, thank you for the correction.

--apb (Alan Barrett)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Sunday, April 14, 2013 at 16:29:38 +0200, Ángel González wrote:
> So you would replace hostname above with eg. ‘expandhost’
> host foo
> expandhost foo.bar.com
>
> The configuration option expandhost would work just like hostname, but
> making foo.bar.com match with the following configuration entries.

I think this is a much cleaner approach than what I proposed; users
don't need to worry about MatchHostName somehow clobbering their
config file, it requires setting one option (ExpandHost) as opposed to
two (HostName & MatchHostName), etc. Seeing that this option had
support in another subthread, I'll update my patch to use ExpandHost
instead.

To those who objected to my initial patch, does this change address
your concerns?

Best wishes,
Ryan

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
On Apr 16, 2013, at 10:52 AM, Ryan Kavanagh <rak@debian.org> wrote:

> On Sunday, April 14, 2013 at 16:29:38 +0200, Ángel González wrote:
>> So you would replace hostname above with eg. ‘expandhost’
>> host foo
>> expandhost foo.bar.com
>>
>> The configuration option expandhost would work just like hostname, but
>> making foo.bar.com match with the following configuration entries.
>
> I think this is a much cleaner approach than what I proposed; users
> don't need to worry about MatchHostName somehow clobbering their
> config file, it requires setting one option (ExpandHost) as opposed to
> two (HostName & MatchHostName), etc. Seeing that this option had
> support in another subthread, I'll update my patch to use ExpandHost
> instead.
>
> To those who objected to my initial patch, does this change address
> your concerns?

I have no more objections anymore.

- Ben
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: [PATCH] Allow matching HostName against Host entries [ In reply to ]
Hi all,

Sorry for the delay, I got caught up with work related things.

On Tue, Apr 16, 2013 at 11:52:48AM -0400, Ryan Kavanagh wrote:
> Seeing that this option had support in another subthread, I'll update
> my patch to use ExpandHost instead.
>
> To those who objected to my initial patch, does this change address
> your concerns?

I've updated the patch, inlined below. I've added the following
additional extensions to the ExpandHost idea:

* Add a "%h" flag to ExpandHost that does the same thing as "%h" in
HostName: substitute in the host passed on the command line

* Add a "%e" flag to HostName that expands to the value of ExpandHost.

These percent-expansions simplify cases like
Host foo
HostName foo.bar.baz
ExpandHost foo.bar.baz
or
Host foo
HostName %h.bar.baz
ExpandHost foo.bar.baz
to the simpler
Host foo
HostName %h.bar.baz
ExpandHost %h.bar.baz
or even simpler, to
Host foo
HostName %e
ExpandHost %h.bar.baz

Note that the ordering of HostName and ExpandHost doesn't matter for the
percent-expansions: %e in HostName gets expanded from ssh.c after the
config file is processed, and nothing in ExpandHost depends on HostName.

Both of these percent-expansions are easy to remove should there be any
objections, but I think both are useful and I can easily think of
real-world use cases for each.

Please let me know if you have any questions/concerns/comments, and if
the patch below addresses the previously raised concerns.

Best wishes,
Ryan

--
|_)|_/ Ryan Kavanagh | Debian Developer
| \| \ http://ryanak.ca/ | GPG Key 4A11C97A

Index: usr.bin/ssh/readconf.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/readconf.h,v
retrieving revision 1.93
diff -u -r1.93 readconf.h
--- usr.bin/ssh/readconf.h 22 Feb 2013 04:45:09 -0000 1.93
+++ usr.bin/ssh/readconf.h 3 May 2013 02:27:33 -0000
@@ -80,6 +80,7 @@
char *kex_algorithms; /* SSH2 kex methods in order of preference. */
int protocol; /* Protocol in order of preference. */
char *hostname; /* Real host to connect. */
+ char *expand_host; /* Possible additional hostname to use in matching. */
char *host_key_alias; /* hostname alias for .ssh/known_hosts */
char *proxy_command; /* Proxy command for connecting the host. */
char *user; /* User to log in as. */
Index: usr.bin/ssh/readconf.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/readconf.c,v
retrieving revision 1.197
diff -u -r1.197 readconf.c
--- usr.bin/ssh/readconf.c 6 Mar 2013 23:36:53 -0000 1.197
+++ usr.bin/ssh/readconf.c 3 May 2013 02:27:36 -0000
@@ -128,7 +128,7 @@
oAddressFamily, oGssAuthentication, oGssDelegateCreds,
oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
oSendEnv, oControlPath, oControlMaster, oControlPersist,
- oHashKnownHosts,
+ oHashKnownHosts, oExpandHost,
oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication,
oKexAlgorithms, oIPQoS, oRequestTTY,
@@ -177,6 +177,7 @@
{ "identityfile2", oIdentityFile }, /* obsolete */
{ "identitiesonly", oIdentitiesOnly },
{ "hostname", oHostName },
+ { "expandhost", oExpandHost },
{ "hostkeyalias", oHostKeyAlias },
{ "proxycommand", oProxyCommand },
{ "port", oPort },
@@ -647,6 +648,16 @@
charptr = &options->hostname;
goto parse_string;

+ case oExpandHost:
+ charptr = &options->expand_host;
+ arg = strdelim(&s);
+ if (!arg || *arg == '\0')
+ fatal("%.200s line %d: Missing argument.",
+ filename, linenum);
+ if (*activep && *charptr == NULL)
+ *charptr = percent_expand(arg, "h", host, (char *)NULL);
+ break;
+
case oHostKeyAlias:
charptr = &options->host_key_alias;
goto parse_string;
@@ -823,7 +834,9 @@
negated = *arg == '!';
if (negated)
arg++;
- if (match_pattern(host, arg)) {
+ if (match_pattern(host, arg) ||
+ (options->expand_host &&
+ match_pattern(options->expand_host, arg))) {
if (negated) {
debug("%.200s line %d: Skipping Host "
"block because of negated match "
@@ -1179,6 +1192,7 @@
options->protocol = SSH_PROTO_UNKNOWN;
options->num_identity_files = 0;
options->hostname = NULL;
+ options->expand_host = NULL;
options->host_key_alias = NULL;
options->proxy_command = NULL;
options->user = NULL;
Index: usr.bin/ssh/ssh.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh.c,v
retrieving revision 1.377
diff -u -r1.377 ssh.c
--- usr.bin/ssh/ssh.c 19 Apr 2013 11:10:18 -0000 1.377
+++ usr.bin/ssh/ssh.c 3 May 2013 02:27:37 -0000
@@ -729,8 +729,13 @@
/* preserve host name given on command line for %n expansion */
host_arg = host;
if (options.hostname != NULL) {
- host = percent_expand(options.hostname,
- "h", host, (char *)NULL);
+ if (options.expand_host != NULL) {
+ host = percent_expand(options.hostname,
+ "h", host, "e", options.expand_host, (char *)NULL);
+ } else {
+ host = percent_expand(options.hostname,
+ "h", host, (char *)NULL);
+ }
}

if (gethostname(thishost, sizeof(thishost)) == -1)
Index: usr.bin/ssh/ssh_config.5
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v
retrieving revision 1.161
diff -u -r1.161 ssh_config.5
--- usr.bin/ssh/ssh_config.5 8 Jan 2013 18:49:04 -0000 1.161
+++ usr.bin/ssh/ssh_config.5 3 May 2013 02:27:39 -0000
@@ -1,4 +1,4 @@
-.\"
+\"
.\" Author: Tatu Ylonen <ylo@cs.hut.fi>
.\" Copyright (c) 1995 Tatu Ylonen <ylo@cs.hut.fi>, Espoo, Finland
.\" All rights reserved
@@ -65,7 +65,10 @@
.Dq Host
specifications, and that section is only applied for hosts that
match one of the patterns given in the specification.
-The matched host name is the one given on the command line.
+The matched host name is the one given on the command line,
+and additionally the value of the
+.Dq ExpandHost
+configuration option once set.
.Pp
Since the first obtained value for each parameter is used, more
host-specific declarations should be given near the beginning of the
@@ -111,6 +114,9 @@
.Ar hostname
argument given on the command line (i.e. the name is not converted to
a canonicalized host name before matching).
+If the
+.Cm ExpandHost
+option has been set, its value is also matched against the patterns.
.Pp
A pattern entry may be negated by prefixing it with an exclamation mark
.Pq Sq !\& .
@@ -434,6 +440,13 @@
.Dq no .
The default is
.Dq no .
+.It Cm ExpandHost
+Specifies an additional string to match against any subsequent
+.Cm Host
+stanza's patterns.
+If the specification contains the character sequence
+.Ql %h ,
+then this will be replaced with the host name specified on the command line.
.It Cm ForwardAgent
Specifies whether the connection to the authentication agent (if any)
will be forwarded to the remote machine.
@@ -593,6 +606,11 @@
.Ql %h ,
then this will be replaced with the host name specified on the command line
(this is useful for manipulating unqualified names).
+If it contains the character sequence
+.Ql %e ,
+then this will be replaced with the value of the
+.Cm ExpandHost
+specification, which must have been set.
The default is the name given on the command line.
Numeric IP addresses are also permitted (both on the command line and in
.Cm HostName
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

1 2  View All