Mailing List Archive

On Sat, 6 Feb 2021 at 05:12, Tim Rice <tim@multitalents.net> wrote:
[...]
> tim@server01-UnixWare 69% hostname
> server01.int.multitalents.net

Sigh. I was wondering if that was going to bite me, but it was OK on
all of the systems I checked. I'll roll it back and add a hostname
function in test-exec.sh similar to the one for egrep which should
also fix the original problem (which was that some platforms don't
have hostname these days).

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Tim Rice wrote:
> > -HOST=`hostname | cut -f1 -d.`
> > -HOSTNAME=`hostname`
> > +HOST=`uname -n | cut -f1 -d.`
> > +HOSTNAME=`uname -n`
>
> This may not work as intended.
> ....
> tim@server01-UnixWare 69% hostname
> server01.int.multitalents.net
> tim@server01-UnixWare 70% uname -n
> server01
> ....

I'll just note that on Debian, Ubuntu, other derivatives (such as
Mint, Trisquel...) both the "uname -n" and "hostname" values would
typically be just the short name. It's not just UnixWare...

rwp@havoc:~$ uname -n
havoc

rwp@havoc:~$ hostname
havoc

Getting a FQDN is truly not trivial. :-(

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 8 Feb 2021 at 09:53, Bob Proulx <bob@proulx.com> wrote:
[...]
> I'll just note that on Debian, Ubuntu, other derivatives (such as
> Mint, Trisquel...) both the "uname -n" and "hostname" values would
> typically be just the short name. It's not just UnixWare...

Double sigh.

Fortunately for this purpose it only matters that the output from
hostname(1) matches the return from gethostname(2), which in this case
it does. so the test still passes on those platforms:

$ cat /etc/lsb-release
[...]
DISTRIB_DESCRIPTION="Ubuntu 20.04.2 LTS"
$ ./ssh -o controlpath='%L' -G ::1 | grep controlpath
controlpath server01
$ ./ssh -o controlpath='%l' -G ::1 | grep controlpath
controlpath server01
$ make t-exec LTESTS=percent TEST_SSH_UNSAFE_PERMISSIONS=1
[...]
ok percent expansions
make[1]: Leaving directory '/home/dtucker/openssh/regress'
all t-exec passed
--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 7 Feb 2021, Bob Proulx wrote:

> I'll just note that on Debian, Ubuntu, other derivatives (such as
> Mint, Trisquel...) both the "uname -n" and "hostname" values would
> typically be just the short name. It's not just UnixWare...

Which I *still* consider a bug, and I set all my systems to use the
FQDN as hostname, so please make sure to test with both ;)

Thanks,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 7 Feb 2021, Bob Proulx wrote:

> rwp@havoc:~$ hostname
> havoc
>
> Getting a FQDN is truly not trivial. :-(

True, and some hostname (ubuntu, centos, etc) implimentations have
"hostname -f" for the FQDN.

--
Tim Rice Multitalents
tim@multitalents.net


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Feb 7, 2021 at 10:21 PM Tim Rice <tim@multitalents.net> wrote:
>
> On Sun, 7 Feb 2021, Bob Proulx wrote:
>
> > rwp@havoc:~$ hostname
> > havoc
> >
> > Getting a FQDN is truly not trivial. :-(
>
> True, and some hostname (ubuntu, centos, etc) implimentations have
> "hostname -f" for the FQDN.

It's especially aggravated by many configuration tools listing the
short hostname first, then the full hostname, in /etc/hosts. i.e.:

127.0.0.1 short.long.com short localhost.localdomian localhost
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Nico Kadel-Garcia wrote:
> Tim Rice wrote:
> > Bob Proulx wrote:
> > > Getting a FQDN is truly not trivial. :-(
> >
> > True, and some hostname (ubuntu, centos, etc) implimentations have
> > "hostname -f" for the FQDN.

That is a dangerous test that if run as root on say HP-UX definitely
(ask me how I know) will set the hostname to "-f"[1] if it has the
permission to do so instead of querying the hostname. The traditional
hostname command took no options and when presented with an argument
would set the hostname to that argument.

[1] https://www.freebsd.org/cgi/man.cgi?query=hostname&manpath=HP-UX+11.22

Additionally hostname -f (--fqdn) performs a DNS look up of the IP
address and returns "a" DNS name found. This is problematic itself in
a number of ways. One being if the host has multiple IP addresses
which individually have different associated names. It's a terrible
non-solution IMNHO.

> It's especially aggravated by many configuration tools listing the
> short hostname first, then the full hostname, in /etc/hosts. i.e.:
>
> 127.0.0.1 short.long.com short localhost.localdomian localhost

I know what you meant to say. But your example showed the reversed
statement in the normal situation with the long name first and the
short name afterward. And the above combination is problematic in
ways that are off-topic to the original problem here.

The /etc/hosts format is usually documented like this:

IP_address canonical_hostname [aliases...]

The first name after the IP address should be the FQDN and is the one
returned when doing a lookup on the IP address. Short names and
aliases appear afterward in the entry line.

In this case, coupled with 127.0.0.1, this creates a problem because
127.0.0.1 should map back to localhost. But adding the long hostname
on that entry causes 127.0.0.1 to map to the long hostname instead of
locahost. However this discussion would be long and off-topic from
the original issue.

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Feb 07, 2021 at 03:43:24PM -0700, Bob Proulx wrote:
> Tim Rice wrote:
> > > -HOST=`hostname | cut -f1 -d.`
> > > -HOSTNAME=`hostname`
> > > +HOST=`uname -n | cut -f1 -d.`
> > > +HOSTNAME=`uname -n`
> >
> > This may not work as intended.
> > ....
> > tim@server01-UnixWare 69% hostname
> > server01.int.multitalents.net
> > tim@server01-UnixWare 70% uname -n
> > server01
> > ....
>
> I'll just note that on Debian, Ubuntu, other derivatives (such as
> Mint, Trisquel...) both the "uname -n" and "hostname" values would
> typically be just the short name. It's not just UnixWare...
>
> rwp@havoc:~$ uname -n
> havoc
>
> rwp@havoc:~$ hostname
> havoc
>
Isn't it just 'hostname -f'?

chris$ hostname -f
t470.zbmc.eu
chris$ hostname
t470


--
Chris Green
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Chris Green wrote:
> Isn't it just 'hostname -f'?
>
> chris$ hostname -f
> t470.zbmc.eu
> chris$ hostname
> t470

The hostname -f option is a "new-ish" Linux specific option. It's not
portable. And because it works by doing a reverse DNS lookup it
depends upon live network connectivity at that moment working for the
network lookup and the results are spotty depending upon how DNS is
set up and how many IP addresses are configured on the host.

It's problematic.

Bob
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, Feb 08, 2021 at 01:54:12PM -0700, Bob Proulx wrote:
> Chris Green wrote:
> > Isn't it just 'hostname -f'?
> >
> > chris$ hostname -f
> > t470.zbmc.eu
> > chris$ hostname
> > t470
>
> The hostname -f option is a "new-ish" Linux specific option. It's not
> portable. And because it works by doing a reverse DNS lookup it
> depends upon live network connectivity at that moment working for the
> network lookup and the results are spotty depending upon how DNS is
> set up and how many IP addresses are configured on the host.
>
Yes, OK, just a thought.

--
Chris Green
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, Feb 8, 2021 at 3:59 PM Bob Proulx <bob@proulx.com> wrote:
>
> Chris Green wrote:
> > Isn't it just 'hostname -f'?
> >
> > chris$ hostname -f
> > t470.zbmc.eu
> > chris$ hostname
> > t470
>
> The hostname -f option is a "new-ish" Linux specific option. It's not
> portable. And because it works by doing a reverse DNS lookup it
> depends upon live network connectivity at that moment working for the
> network lookup and the results are spotty depending upon how DNS is
> set up and how many IP addresses are configured on the host.
>
> It's problematic.
>
> Bob

It looks in /etc/hosts first, which works very well when DNS is
unavailable and when the host his publishing a dynamic DNS entry.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, 9 Feb 2021 at 11:35, Nico Kadel-Garcia <nkadel@gmail.com> wrote:
[about hostname -f]
> It looks in /etc/hosts first, which works very well when DNS is
> unavailable and when the host is publishing a dynamic DNS entry.

It *might* look in /etc/hosts first, depending on what's in
/etc/nsswitch.conf. At least with glibc anyway, other libc
implementations might do something different again. Anyway it's far
enough into "it depends" that it's not something I'd want to rely on,
and as it stands it looks like we don't need to.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 09.02.21 01:25, Nico Kadel-Garcia wrote:
> On Mon, Feb 8, 2021 at 3:59 PM Bob Proulx <bob@proulx.com> wrote:
>> The hostname -f option is a "new-ish" Linux specific option. It's not
>> portable. And because it works by doing a reverse DNS lookup it
>> depends upon live network connectivity at that moment working for the
>> network lookup and the results are spotty depending upon how DNS is
>> set up and how many IP addresses are configured on the host.
>
> It looks in /etc/hosts first, which works very well when DNS is
> unavailable and when the host his publishing a dynamic DNS entry.

Suffice to say that I added a check to our monitoring so as to detect
machines entering production where `hostname`, not to even mention
/etc/hosts, still returns "localhost.localdomain" or even just
"localhost" instead of something unique.

Out of interest, what *purpose* is the obtained hostname being used for?
Does OpenSSH actually *need* it to be a) unique, b) reproducible, and/or
c) a proper FQDN, or does it merely enter the comment of autogenerated
host keypairs? All the KnownHosts checking AFAIR happens on the *client*
side and uses whatever name(s) of the server are known *there* ...

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

On Tue, 9 Feb 2021 at 19:05, Jochen Bern <Jochen.Bern@binect.de> wrote:
[...]
> Out of interest, what *purpose* is the obtained hostname being used for?

For the case that started this thread, it's used for expanding "%"
tokens in the config file. From ssh_config(5):

TOKENS
Arguments to some keywords can make use of tokens, which are expanded at
runtime:
[...]
%L The local hostname.
%l The local hostname, including the domain name.

These can be used by various keywords, typically for file paths (for
example, if you want to make a ControlPath unique to a hostname). I'd
have to check the code history to figure out where each token
originally came from, but I made them all more or less consistent
between the 8.2 and 8.3 releases.

> Does OpenSSH actually *need* it to be a) unique, b) reproducible, and/or
> c) a proper FQDN

Depends on what the user uses them for, but typically as long as
they're reproducible and unique within a set of machines that share a
filesystem it would likely be sufficient.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Tue, 9 Feb 2021, Darren Tucker wrote:

> %L The local hostname.
> %l The local hostname, including the domain name.

Given the trouble in obtaining the local FQDN, it might make sense
to redocument them as:

%L The local hostname, with the domain name stripped off.
%l The local hostname.

This wouldn’t change anything on correctly set-up systems, and
on all others, %l would just be the same as %L and it wouldn’t
mismatch the documentation. From the context (these lines being
adjacent) it’d be clear as well.

bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

*************************************************

Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.

Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.

*************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev