When connecting to a new computer using hostname, ~/.ssh/known_hosts is fed with hostname converted to lower.case.
Example :
:~> ssh some_user@15-3-MY-SERVER-LINUX
The authenticity of host '[**15-3-my-server-linux**]:12345 ([192.168.1.3]:12345)' can't be established.
RSA key fingerprint is SHA256:sf0UBJQq9aLDiRCzPxCYAe4nvydALe83oUptHBbj6Tc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[**15-3-my-server-linux**]:12345' (RSA) to the list of known hosts.
DD-WRT v3.0-r47495 std (c) 2021 NewMedia-NET GmbH
Release: 09/28/21
Board: Netgear R6300V2
some_user@15-3-my-server-linux's password:
Permission denied, please try again.
Because there is no difference between my-server-linux, MY-SERVER-LINUX, My-Server-Linux, mY-sERVER-lINUX and all other permutations of upper- and lower-case Latin characters as host name, SSH apparently prefers to store all in lower case for easy implementation of test, etc.
IMHO filing a bug report about this is a waste of time for you and for others.
Itâs not causing a problem, so itâs unlikely to be âfixedâ. Itâs working as designed.
Converting to lowercase for storage likely makes the code simpler, but if you really want it to be uppercase, you can edit the known_hosts file and try changing it to see if that preserves the case you want. I donât know whether itâll work or not, but you can certainly try.
As others said, not worth reporting as a bug because itâs working as designed, and quite possibly if you wanted it to be addressed, youâd have to report it upstream to the openssh project - but again, I would suspect that the bug would be rejected as WONTFIX because itâs been this way forever.
BTW: When replacing host erlangenâs 6700K CPU by a 5700G I assembled a new desktop machine and name it 6700K.
The uppercase character K worked fine but it created distracting messages during maintenance. I renamed the host to 6700k. Renaming to lowercase k fixed this issue.
So how could you ssh to âsome_user@15-3-MY-SERVER-LINUXâ with a âknown_hostâ which contains something like â[15-3-my-server-linux]:11945 ecdsa-sha2-nistp256 âŚâ
If ssh convert uppercase to lowercase when registering to known_hosts, then hostname should be lower case and then hostname are not case insensitive.
henk@boven:~> ssh beneden
The authenticity of host 'beneden (10.0.0.155)' can't be established.
ECDSA key fingerprint is SHA256:Q+k9lHw/GcojfQ2gM51ntRyRD0uXxOvEqq9+6Odyjg4.
Are you sure you want to continue connecting (yes/no/[fingerprint])? no
Host key verification failed.
henk@boven:~> ssh Beneden
The authenticity of host 'beneden (10.0.0.155)' can't be established.
ECDSA key fingerprint is SHA256:Q+k9lHw/GcojfQ2gM51ntRyRD0uXxOvEqq9+6Odyjg4.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
I see no difference when I change a character into uppercase.
Lowercase is the norm (I assume nobody even would think about using uppercase in the time of the TTY) and when you use uppercase, that is on the spot corrected.
If it doesnât work, you may have defined a host in ~/.ssh/config on the client machine - that file is case-sensitive (I just learned that myself by trying it). But if itâs not configured in that manner:
[jhenderson@TheEarth ~]$ ssh pi@zarss
Linux zarss 5.15.84+ #1613 Thu Jan 5 11:58:09 GMT 2023 armv6l
[...]
Last login: Wed May 31 07:01:23 2023 from 172.16.0.170
pi@zarss:~ $
logout
Connection to zarss closed.
[jhenderson@TheEarth ~]$ ssh pi@ZARSS
Linux zarss 5.15.84+ #1613 Thu Jan 5 11:58:09 GMT 2023 armv6l
[...]
Last login: Wed May 31 07:03:34 2023 from fdab:e9e5:9bff::871
pi@zarss:~ $
If you re-read my post #1, you will see that the host is defined in known_hosts files by ssh because the host name does not exists :
..................... Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
And I have not seen that the reference was converted to lower case.
So now I have 2 choices :
1°) I edit the the known_hosts file on the client with uppercase for the hostname. That implie that the hostname in not encrypted in the public key
2°) i change the hostname on the distant machine.
If âAâ (hostname) has a property âcase insensitiveâ ; if âBâ (computer address in ssh command) has a property âcase insensitiveâ ; if C is writing some kind of rules by converted a key from current letter case to lowercase then from my point of view then C break the insensitive property rule.
The host name is not part of the public key/private key pair. From my example, you can see that connecting with either uppercase or lowercase is not inhibited by the fact that I am not prompted to approve the fingerprint.
If you are prompted for the fingerprint, itâs possible that youâve got the host defined in the .ssh/config file, which for some reason is case sensitive.
If you really feel this is a bug, go ahead and open one. I can tell you, though, that it will likely be rejected because it is working as designed.