Hello - I am running an OpenSuSE 15.3 x64 system where I am also running a NAMED server for my network.
quasar:/etc/named.d # named -v BIND 9.16.6 (Stable Release) <id:25846cf> quasar:/etc/named.d # ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 Apparently recently something has changed which is now breaking SSH's ability to connect to a URL with upper case letters in the host name. (I connect and use SSH within a port knocking script which has worked for many years, so I know it is not caused by something I am doing, but by a change that has occurred within either SSH or NAMED.) Internet and Googling searches seem to imply that Bind (NAMED) is now resolving URL's in a case sensitive fashion. https://kb.isc.org/docs/aa-01113 and I suspect this change has just now caught up with me.
But, I don't know if the fault lies entirely with Bind/NAMED. SSH appears to be mangling URLs, changing upper case letters within a URL, to lower case before asking a name server to resolve them. (IMHO this is extremely bad behavior on SSH's part because it is destroying user supplied data, something a program should never do!) Here is an example of what I am seeing that leads me to this conclusion -
ssh marc@darkstarINT.mydomain.com ssh: connect to host darkstarint.mydomain.com port 22: No route to host
Notice SSH changed the upper case "INT" in the host name "darkstarINT" to a lower case "int" in the query. I checked the log file at /var/log/named/named and indeed saw the query for the URL, from SSH, was all lower case. The message "No route to host" is misleading (probably because of bad error handling) and just means SSH was unable to get an IP address from the DNS server for the URL host name, that it mangled. Doing some further Googling, I found some references to using an ACL declaration in the NAMED configuration files, but I am unable to find any easy/clear guidance or examples on how to do this. Does anyone here know either how to keep SSH from converting a URL, that it is querying, to stop this horrid conversion of a URL to all lower case, or how to get NAMED to handle queries in a case insensitive manner? (perhaps using the ACL declaration that I found some references to.) If not, does anyone know of a better forum I could ask? Links to documentation, with examples, would also be appreciated, after hours of searching I was not able to find anything helpful. I know I could go through all my NAMED configuration files and and either add duplicate zones or use CNAME perhaps to add in all lower case equivalent host names but that seems like a huge burden and a bunch of extra maintenance overhead. Thanks and as always appreciate thoughts, ideas, and the time it takes to write a reply... Marc... -- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
From: Marc Chamberlin <marc@marcchamberlin.com> Date: Wed, 8 Mar 2023 14:04:48 -0800 Hello - I am running an OpenSuSE 15.3 x64 system where I am also running a NAMED server for my network.
quasar:/etc/named.d # named -v BIND 9.16.6 (Stable Release) <id:25846cf> quasar:/etc/named.d # ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 Apparently recently something has changed which is now breaking SSH's ability to connect to a URL with upper case letters in the host name. (I connect and use SSH within a port knocking script which has worked for many years, so I know it is not caused by something I am doing, but by a change that has occurred within either SSH or NAMED.) Internet and Googling searches seem to imply that Bind (NAMED) is now resolving URL's in a case sensitive fashion. https://kb.isc.org/docs/aa-01113 and I suspect this change has just now caught up with me.
But, I don't know if the fault lies entirely with Bind/NAMED. SSH appears to be mangling URLs, changing upper case letters within a URL, to lower case before asking a name server to resolve them. (IMHO this is extremely bad behavior on SSH's part because it is destroying user supplied data, something a program should never do!) Here is an example of what I am seeing that leads me to this conclusion -
ssh marc@darkstarINT.mydomain.com ssh: connect to host darkstarint.mydomain.com port 22: No route to host
Notice SSH changed the upper case "INT" in the host name "darkstarINT" to a lower case "int" in the query. I checked the log file at /var/log/named/named and indeed saw the query for the URL, from SSH, was all lower case. The message "No route to host" is misleading (probably because of bad error handling) and just means SSH was unable to get an IP address from the DNS server for the URL host name, that it mangled. Since Day 1, DNS has been case-insensitive, and as far as I know, the ssh client has always made its DNS queries in lowercase, so I don't think DNS is your problem. Try doing ssh -vvv marc@darkstarINT.mydomain.com and tell us what ssh says. -- Bob Rogers http://www.rgrjr.com/
On 3/8/23 18:49, Bob Rogers wrote:
From: Marc Chamberlin <marc@marcchamberlin.com> Date: Wed, 8 Mar 2023 14:04:48 -0800
Hello - I am running an OpenSuSE 15.3 x64 system where I am also running a NAMED server for my network.
> quasar:/etc/named.d # named -v > BIND 9.16.6 (Stable Release) <id:25846cf> > quasar:/etc/named.d # ssh -V > OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 Apparently recently something has changed which is now breaking SSH's ability to connect to a URL with upper case letters in the host name. (I connect and use SSH within a port knocking script which has worked for many years, so I know it is not caused by something I am doing, but by a change that has occurred within either SSH or NAMED.) Internet and Googling searches seem to imply that Bind (NAMED) is now resolving URL's in a case sensitive fashion. https://kb.isc.org/docs/aa-01113 and I suspect this change has just now caught up with me.
But, I don't know if the fault lies entirely with Bind/NAMED. SSH appears to be mangling URLs, changing upper case letters within a URL, to lower case before asking a name server to resolve them. (IMHO this is extremely bad behavior on SSH's part because it is destroying user supplied data, something a program should never do!) Here is an example of what I am seeing that leads me to this conclusion -
> ssh marc@darkstarINT.mydomain.com > ssh: connect to host darkstarint.mydomain.com port 22: No route to host
Notice SSH changed the upper case "INT" in the host name "darkstarINT" to a lower case "int" in the query. I checked the log file at /var/log/named/named and indeed saw the query for the URL, from SSH, was all lower case. The message "No route to host" is misleading (probably because of bad error handling) and just means SSH was unable to get an IP address from the DNS server for the URL host name, that it mangled.
Since Day 1, DNS has been case-insensitive, and as far as I know, the ssh client has always made its DNS queries in lowercase, so I don't think DNS is your problem. Try doing
ssh -vvv marc@darkstarINT.mydomain.com
and tell us what ssh says.
-- Bob Rogers http://www.rgrjr.com/
Totally agree with your comments about DNS and SSH, and I said as much, but something did break my scripts suddenly. Internet searches imply that DNS/Bind/Named are going towards using case-sensitive compression and I am wondering if this change finally caught up with me and what to do about it. Read the document at isc.org which I provided a link to. Maybe I do have a configuration error in the configuration files for my DNS server and I will continue to look into it. Here is the output I got from trying to use ssh with 3 v's used to increase the debugging messages...
ssh -vvv marc@darkstarINT.mydomain.com OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/root/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2' debug2: resolving "darkstarint.mydomain.com" port 22 ssh: Could not resolve hostname darkstarint.mydomain.com: Name or service not known I don't see anything helpful but maybe your eyes are better than mine... Any more good ideas? Thank you, Marc...
-- *"The Truth is out there" - Spooky* *_ _ . . . . . . _ _ . _ _ _ _ . . . . _ . . . . _ _ . _ _ _ . . . . _ _ . _ . . _ . _ _ _ _ . _ . _ . _ . _ . * Computers: the final frontier. These are the voyages of the user Marc. His mission: to explore strange new hardware. To seek out new software and new applications. To boldly go where no Marc has gone before! (/This email is digitally signed and the OpenPGP electronic signature is added as an attachment. If you know how, you can use my public key to prove this email indeed came from me and has not been modified in transit. My public key, which can be used for sending encrypted email to me also, can be found at - https://keys.openpgp.org/search?q=marc@marcchamberlin.com or just ask me for it and I will send it to you as an attachment. If you don't understand all this geek speak, no worries, just ignore this explanation and ignore the OpenPGP signature key attached to this email (it will look like gibberish if you open it) and/or ask me to explain it further if you like./)
From: Marc Chamberlin <marc@marcchamberlin.com> Date: Wed, 8 Mar 2023 20:54:10 -0800 Totally agree with your comments about DNS and SSH, and I said as much, but something did break my scripts suddenly. Internet searches imply that DNS/Bind/Named are going towards using case-sensitive compression and I am wondering if this change finally caught up with me and what to do about it. Read the document at isc.org which I provided a link to. So your theory is that BIND is being case-sensitive (because your zone file is) and SSH is still assuming case-insensitivity when it does case-folding of the name you give it . . . Maybe I do have a configuration error in the configuration files for my DNS server and I will continue to look into it. Here is the output I got from trying to use ssh with 3 v's used to increase the debugging messages...
ssh -vvv marc@darkstarINT.mydomain.com OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/root/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2' debug2: resolving "darkstarint.mydomain.com" port 22 ssh: Could not resolve hostname darkstarint.mydomain.com: Name or service not known
I don't see anything helpful but maybe your eyes are better than mine... Any more good ideas? Thank you, Marc... OK, so it's definitely the DNS lookup that is failing for SSH. Presumably "dig" on your system will find the host correctly, because it is part of the same BIND release. If you can sniff the network traffic from that transaction, and it shows that BIND hasn't diddled the case, and "dig" fails if you give it any other mixed case, then that would seem to prove you correct. -- Bob
Marc Chamberlin wrote:
it. Here is the output I got from trying to use ssh with 3 v's used to increase the debugging messages...
ssh -vvv marc@darkstarINT.mydomain.com OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 20: Applying options for * debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/root/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/root/.ssh/known_hosts2' debug2: resolving "darkstarint.mydomain.com" port 22 ssh: Could not resolve hostname darkstarint.mydomain.com: Name or service not known I don't see anything helpful but maybe your eyes are better than mine... Any more good ideas? Thank you, Marc...
Did you actually replace "mydomain.com" with whatever.your.domain is ? -- Per Jessen, Zürich (11.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Marc Chamberlin wrote:
Hello - I am running an OpenSuSE 15.3 x64 system where I am also running a NAMED server for my network.
quasar:/etc/named.d # named -v BIND 9.16.6 (Stable Release) <id:25846cf>
Same here, albeit on Leap 15.2.
quasar:/etc/named.d # ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019
Roughly the same here, depending on which system. I like how you are careful with describing the context, +1
Apparently recently something has changed which is now breaking SSH's ability to connect to a URL with upper case letters in the host name.
First of all, lower/upper case is irrelevant in DNS. It does look as if ssh sort of looks at case though - at least when it comes to managing known_hosts. Interesting.
(I connect and use SSH within a port knocking script which has worked for many years, so I know it is not caused by something I am doing, but by a change that has occurred within either SSH or NAMED.) Internet and Googling searches seem to imply that Bind (NAMED) is now resolving URL's in a case sensitive fashion.
Not here. I have a host called 'gaston' - using host or dig (or ssh), lower/upper case, it always resolves correctly.
https://kb.isc.org/docs/aa-01113 and I suspect this change has just now caught up with me.
It seems to be specifically related to response compression, I'm not sure when that is used.
But, I don't know if the fault lies entirely with Bind/NAMED.
What _is_ the fault? if it is "breaking SSH's ability to connect to a URL with upper case letters in the host name", I cannot confirm - it works fine here.
SSH appears to be mangling URLs, changing upper case letters within a URL, to lower case before asking a name server to resolve them.
Wait - lets get the terminology right. ssh does not deal with URLs, only with hostnames and/or -addresses. I agree ssh should not be changing anything in a URL, but folding a hostname to lower case before resolving it should not have _any_ impact on the resolution of the name.
(IMHO this is extremely bad behavior on SSH's part because it is destroying user supplied data, something a program should never do!) Here is an example of what I am seeing that leads me to this conclusion -
ssh marc@darkstarINT.mydomain.com ssh: connect to host darkstarint.mydomain.com port 22: No route to host
Notice SSH changed the upper case "INT" in the host name "darkstarINT" to a lower case "int" in the query.
Yup, same behaviour here.
Doing some further Googling, I found some references to using an ACL declaration in the NAMED configuration files, but I am unable to find any easy/clear guidance or examples on how to do this.
Using ACLs is no big deal, but I don't see what you're trying to achieve. We can start another thread on that if you want.
Does anyone here know either how to keep SSH from converting a URL, that it is querying, to stop this horrid conversion of a URL to all lower case, or how to get NAMED to handle queries in a case insensitive manner?
I think you are jumping to solutions. Maybe try the following on your system, to confirm if your DNS is case-insensitive (or not): host darkstarINT.mydomain.com host darkstarint.mydomain.com Next, maybe try both variations with ssh: ssh darkstarINT.mydomain.com ssh darkstarint.mydomain.com -- Per Jessen, Zürich (7.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2023-03-08 at 14:04 -0800, Marc Chamberlin wrote:
Hello - I am running an OpenSuSE 15.3 x64 system where I am also running a NAMED server for my network.
quasar:/etc/named.d # named -v BIND 9.16.6 (Stable Release) <id:25846cf> quasar:/etc/named.d # ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1d 10 Sep 2019 Apparently recently something has changed which is now breaking SSH's ability to connect to a URL with upper case letters in the host name. (I connect and use SSH within a port knocking script which has worked for many years, so I know it is not caused by something I am doing, but by a change that has occurred within either SSH or NAMED.) Internet and Googling searches seem to imply that Bind (NAMED) is now resolving URL's in a case sensitive fashion. https://kb.isc.org/docs/aa-01113 and I suspect this change has just now caught up with me.
My machine Isengard was updated from 15.2 to 15.3 this week, and within hours to 15.4, and is running named, so I'll test. I also use some times upper case names, since ever. I don't remember configuring for this. cer@Telcontar:~/Download/Firefox_downloads> ssh cer@isengard.valinor Last login: Mon Mar 6 03:52:27 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> logout Connection to isengard.valinor closed. cer@Telcontar:~/Download/Firefox_downloads> ssh cer@Isengard.Valinor Last login: Thu Mar 9 11:18:26 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> named -v Absolute path to 'named' is '/usr/sbin/named', so running it may require superuser privileges (eg. root). cer@Isengard:~> /usr/sbin/named -v BIND 9.16.37 (Extended Support Version) <id:2b2afb2> cer@Isengard:~> ssh -V OpenSSH_8.4p1, OpenSSL 1.1.1l 24 Aug 2021 SUSE release 150400.7.25.1 cer@Isengard:~> sshd -V Absolute path to 'sshd' is '/usr/sbin/sshd', so running it may require superuser privileges (eg. root). cer@Isengard:~> /usr/sbin/sshd -V unknown option -- V OpenSSH_8.4p1, OpenSSL 1.1.1l 24 Aug 2021 SUSE release 150400.7.25.1 usage: sshd [-46DdeiqTt] [-C connection_spec] [-c host_cert_file] [-E log_file] [-f config_file] [-g login_grace_time] [-h host_key_file] [-o option] [-p port] [-u len] cer@Isengard:~> cer@Isengard:~> ssh cer@telcontar.valinor Password: Last login: Mon Jan 30 14:18:41 2023 Have a lot of fun... If you wish women to love you, be original; I know a man who wore fur boots summer and winter, and women fell in love with him. -- Anton Chekhov cer@Telcontar:~> logout Connection to telcontar.valinor closed. cer@Isengard:~> ssh cer@Telcontar.Valinor Password: Last login: Thu Mar 9 11:19:31 2023 from 192.168.1.16 Have a lot of fun... Laugh, and the world ignores you. Crying doesn't help either. cer@Telcontar:~> logout Connection to telcontar.valinor closed. cer@Isengard:~> logout Connection to isengard.valinor closed. cer@Telcontar:~/Download/Firefox_downloads>
But, I don't know if the fault lies entirely with Bind/NAMED. SSH appears to be mangling URLs, changing upper case letters within a URL, to lower case before asking a name server to resolve them. (IMHO this is extremely bad behavior on SSH's part because it is destroying user supplied data, something a program should never do!) Here is an example of what I am seeing that leads me to this conclusion -
ssh marc@darkstarINT.mydomain.com ssh: connect to host darkstarint.mydomain.com port 22: No route to host
cer@Telcontar:~/Download/Firefox_downloads> ssh cer@Isengard.Valinor Last login: Thu Mar 9 11:27:12 2023 from 192.168.1.14 Have a lot of fun... cer@Isengard:~> ssh marc@darkstarINT.mydomain.com ssh: Could not resolve hostname darkstarint.mydomain.com: Name or service not known cer@Isengard:~>
Notice SSH changed the upper case "INT" in the host name "darkstarINT" to a lower case "int" in the query. I checked the log file at /var/log/named/named and indeed saw the query for the URL, from SSH, was all lower case. The message "No route to host" is misleading (probably because of bad error handling) and just means SSH was unable to get an IP address from the DNS server for the URL host name, that it mangled.
Well, AFAIK that all software that don't differentiate for case do the same. They either convert to upper case or lowercase as part of the process. I believe that the library functions that compare strings without caring for case do the same thing, convert both strings to upper case before comparing.
Doing some further Googling, I found some references to using an ACL declaration in the NAMED configuration files, but I am unable to find any easy/clear guidance or examples on how to do this.
Isengard:~ # grep -i ACL /etc/named.conf Isengard:~ # grep -i ACL /etc/named.d/* Isengard:~ #
Does anyone here know either how to keep SSH from converting a URL, that it is querying, to stop this horrid conversion of a URL to all lower case, or how to get NAMED to handle queries in a case insensitive manner? (perhaps using the ACL declaration that I found some references to.) If not, does anyone know of a better forum I could ask? Links to documentation, with examples, would also be appreciated, after hours of searching I was not able to find anything helpful.
I know I could go through all my NAMED configuration files and and either add duplicate zones or use CNAME perhaps to add in all lower case equivalent host names but that seems like a huge burden and a bunch of extra maintenance overhead.
Isengard:/var/lib/named # grep -i legolas valinor.zone Legolas A 192.168.1.126 MX 10 Legolas Legolas-e A 192.168.1.127 MX 10 Legolas Isengard:/var/lib/named # host lEgolas Legolas.valinor has address 192.168.1.126 Legolas.valinor mail is handled by 10 Legolas.valinor. Isengard:/var/lib/named #
Thanks and as always appreciate thoughts, ideas, and the time it takes to write a reply... Marc...
Welcome :-) - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZAm42Rwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV9YwAn0J8LyNKuooIg8gwQO11 KoQdj77bAJ9PhXAa/eiJ65u8TH6x2SRAT212Sw== =kq2s -----END PGP SIGNATURE-----
participants (4)
-
Bob Rogers -
Carlos E. R. -
Marc Chamberlin -
Per Jessen