Their 10.15.4 macOS built-in ssh terminal command is unable to reach hostnames when a port number higher than 8192 is used.

EDIT:

Comments differ; one indicates issues SSH'ing to lower than 8192 ports, another indicates no issues SSH'ing to higher than 8192 ports.

This complain and Remote Access in (so I can SSH to my $4k MacBook) disables itself anytime the computer is restarted.

But more importantly, I’ve still not found a Thunderbolt Display that doesn’t routinely crash screen manager services upon idle user activity. 3 x $300 thunderbolt3 dock solutions later and not a one hasn’t crashed this computer. All main brands, two of which sell accessories in the Apple store.

Problem also existed with a top of the line 13” MacBook Pro.

I’ve just gotten used to the shoddy-ness that is Catalina. Figure if I go to the bathroom, upon return I have a fresh, new clean desktop environment. Feature not a bug. Yay!

In his screenshot the bad login hangs at "Connecting to clickontyler.com port" (noting that no port number appears and no period at the end).

While I can’t be sure exactly which "ssh" patch Apple may have, this seems to be the relevant file and logging code (starting at line 448):

https://github.com/openssh/openssh-portable/blob/master/sshc...

In that code, the only thing that can set the "strport" value that is used in the log is a call to getnameinfo().

If that string is corrupted in any way, e.g. not terminated or perhaps has invisible characters that trigger bad terminal behavior (such as invisibility), the act of logging it might produce the apparent hang seen here.

Again, a guess but it is possible that getnameinfo() is not necessarily processing the record correctly (for whatever reason). One such example is in the "getnameinfo" man page at the end, under CAVEATS, where they show an example of not simply trusting the result of the first call.

* https://openradar.appspot.com/radar?id=4931259776106496

From that and the discussions.apple.com. post, hyperlinked elsewhere in this discussion, it appears that the >8192 condition varies according to what the hostname actually is.

The bug report is datelined 2020-04-26, interestingly. There might be a bug in the bug reporting system. (-:

> debug1: resolve_canonicalize: hostname example.org:7999 is an unrecognised address

If instead I use `-p` or a config-file option, everything works as expected.

(Guest in my test: OpenSSH 7.6p1 on ubuntu bionic, stock config other than sshd port.)

EDIT: Thanks to everyone who answered my question! It makes sense to me now why one might do this.

Thank you about that clarification. Also your website seems to be down actually.

+1

My Mac's resources were getting gobbled up by an internal process I coudln't terminate and my keychain was borked and I couldn't log in after a reset (to try and get around the resource hogging). Recovery didn't get me any where so I used Recovery over the Internet to do a clean install.

I'm running 10.15.4, no issues as of yet. And this all occurred after the security update. I'm running on the version prior for now but will make sure I've got a good backup and give it another go.

  sudo softwareupdate --ignore "macOS Catalina"
  defaults write com.apple.systempreferences AttentionPrefBundleIDs 0
  killall Dock

Is that a common thing to do, or any reason why the OP would do that? Doesn't ssh reject your key, saying it does that if there's such a problem? And even if not wouldn't it be advisable to at least look at the permissions; I mean suppose they're not -rw------- or so, wouldn't you want to know that, and also why they are not ok?

One might uncharitably suggest that using macOS and expecting standard decades-old Unix behaviour is itself bizarre … but that's also true of using Linux with systemd (viz., nohup no longer nohups, or systemd-resolved, or innumerable other broken bits).

It's almost as though no-one cares about quality anymore.

However, there is an amazingly easy workaround, assuming the IP and port don’t change often: create a ~/bin shell script that connects via IP and port, make it executable, and add ~/bin to PATH.

This workaround doesn’t excuse Apple of doing something so egregiously stupid, but it’s so easy that you may as well do it and move on.

I tested this specifically on a number of servers that I run with port numbers > 10000, using /usr/bin/ssh on macOS 10.15.4, with and without IP addresses. Nothing broke for me.

Still not sure if that is my machine, or a general fault - but the lack of monitor and promiscuous mode is playing havoc with IPv6 multicast packets from VMware Fusion VMs.

I love having the Linux kernel with a nice UI but there are some useful commands that are missing.

There are ways to get them set up but in any case it’s kind of a pain

Have had no issues with it at all.

Whoops

Someone should have paid more attention to that verbose SSH output first.

'ssh -4 <hostname>'

Welp.

Ends up on Hacker News again bitching about Catalina.

lol

I was completely at my wit’s end and feeling like I had lost my mind until about a half hour ago. Let me start from the beginning…

I don’t have an exact date, but within the last week I realized that I was unable to ssh into my primary web server – the one that runs my business website, activation server, etc. It’s sort of the linchpin for my tiny software company. When it goes down, I get worried.

At first I thought maybe the server was down? I hadn’t received any alerts, so I did a quick check. And, yes, it was still up and running and serving web traffic. Ok, did sshd somehow become unresponsive? I login through the Linode control panel and restart the service. Still can’t login.

It’s odd. I don’t get a connection refused. Not even a timeout. It just…hangs.

That’s the ssh output with the verbose flag. Nothing. I waited 10+ minutes and it never timed out or produced any other output.

I reboot the server itself and the problem persists.

Then, I notice some more oddities. I’m able to connect using ForkLift – my FTP client, which connects via SFTP. Also, SequelPro is able to connect to MySQL via ssh as well.

And then things get even stranger. This is all happening on my iMac. I try connecting from my laptop, and it works. My MacBook Pro is at home right next to my iMac, which is refusing to login. They’re both on the same wifi and thus the same IP. So, it can’t be that my home IP address got mistakenly banned somehow.

Next, I ssh into a different server and then hop to the problematic one. It connects without any trouble. At this point I’m thinking maybe the permissions on my local private key got screwed up. So, I blow away ~/.ssh and recreate all of my keys from a backup. Still can’t login.

Ok. I think about it for a few minutes and then – aha! – I have an Ubuntu virtual machine running on this iMac inside Parallels. I’ll ssh into it and then try and connect. That will rule out if there’s just something odd about my iMac’s LAN IP. (To be clear, my home network is perfectly ordinary. Just a cable modem and a router.) So, I login to the VM, try and connect, and it works fine.

At this point here’s what I’ve found:

My iMac is the only machine that cannot login. I’ve connected successfully from behind the same public IP using a laptop, a virtual machine, and my iPhone and iPad. I’ve verified my ssh keys are correct and have the appropriate permissions. I can connect to other servers from the problematic machine – both at the same hosting provider (Linode) and others (AWS and DigitalOcean). I can connect from my iMac if I jump through any other server, first. I start trying to think what could possibly be different about this one machine. And then it dawns on me. This all started around the time I updated my iMac to 10.15.4. My laptop is still on 10.15.3 – and, of course, the virtual machine isn’t macOS at all.

Totally grasping for straws I google for “10.15.4 ssh” and find this top result on the Apple discussion forums:

Catalina 10.15.4 SSH port > 8192 does not work when using server name instead of IP

This issue started just after upgrading to macOS Catalina 10.15.4.

After that update I am no longer able to open a SSH connection to a port greater than 8192 using server name (instead of IP). Yes, I do change the port on the server side prior to every test.

That can’t possibly be real?

Up until this point, I was connecting via a saved hostname defined in my ~/.ssh/config, which let me login simply by tying ssh some-server. So, I tried ssh ip-address -p9944 and it worked! (That server runs on an alternate ssh port.)

Ok. Time to narrow this down a bit further. I changed the server to listen on standard port 22 and tried connecting via the hostname once again.

Holy crap, it worked.

The user in the Apple forums was right. At least in my case, my one server that happened to be running on a non-standard ssh port above 8192 will not connect from Catalina 10.15.4 when using the hostname instead of the IP address.

Just to verify, I boot up a Mojave and Catalina (10.15.3) VM on the same iMac. They both connect fine, while the host machine continues to fail.

The internals of this is all so incredibly above my head I have no idea what the underlying problem might be. Am I and this one other forum poster just doing something totally bizarre yet the same? This ssh setup has been working for years for me until just the last week. I would love to be proven wrong and told I’m an idiot. But I don’t know what difference connecting via the hostname versus the IP address would make when specifically using a non-standard port above a certain threshold.

It just….sigh.

I’m not even going to go into it. I don’t want to end up on Hacker News again bitching about Catalina. I just hope I’ve stuffed this post with enough keywords so that anyone else searching on Google might come across the answer.

Hahaha

Shocking!

Granted high ports shouldn't be broken, but running SSH on a non-standard port is security (read obscurity) theater at best.

There's really not much benefit, unless you need multiple sshds on the same IP, but at that point I'd question the sanity of the approach.