Can't SSH to host via Internet, but connectivity is allow and working

I noticed I can't start a CLI (Terminal, for the sake of this audience) SSH session to a remote host via Internet. I know the port 22 traffic is permitted on both firewalls based on the following evidence:


1) Running nc to the same IP address shows a good connection

2) Connecting from behind the same Public IP from a Windows PC running Xterm, the SSH session works fine


Also interesting: if I'm behind the same firewall as the SSH server and access it via a carrier-grade NAT (100.64.0.0/10) IP address, connection is OK.


My hunch here is there's a security setting in MacOS that dis-allows SSH connections via Internet. As additional evidence running a `sudo tcpdump -n -i en0 22`, I see absolutely nothing when using the ssh command. But I do see plenty of traffic by connecting to the same host via nc, curl, etc. So the connection really seems to be squashed at the software layer.




MacBook Pro 13″, macOS 10.13

Posted on Nov 8, 2023 8:44 PM

Reply
Question marked as Top-ranking reply

Posted on Nov 14, 2023 2:28 PM

johnnylingo wrote:

> This would imply the remote system is not responding to your ssh request.

Or it could also imply the local system (the mac) never attempted the outbound connection

No. If the local system could not make the connection, it would have come back immediately. It would not hang.


ssh works on Mac, and has been working since the Mac OS X releases back in the early 2000's. I've been personally using ssh on my Mac everyday, all day, since 2005 as part of my day job.

> I assume if you leave the request long enough, it times out.

No, there is no error message or timeout because the client never attempted the outbound connection
> macOS is attempting to connect, but not getting a response.

No, it's not attempting to connect at all, as demonstrated by running tcpdump -i en0 -n port 22

Have you tried that tcpdump command on a working ssh connection to make sure all the options are correct?


On my Mac I see:

debug1: Connecting to development.system.mycompany.com [nn.nn.nn.nn] port 22.

debug1: Connection established.


Is this the /usr/bin/ssh version? I just want to insure that a different ssh version was installed./usr/bin/ssh

> This also implies that remoteserver.com port 22 is open, as a closed port would return immediately.

Yes, closed ports typically show 'connection refused' or similar

> It also implies that there is a process listening on port 22, but not responding, otherwise the port would not be open.

Yes, there is of course, as I can connect to it fine running nc, and packet captures on the remote end confirm that.

> I do not think this is a firewall issue on either system, as a firewall blocking the connection would just reject the connection request, not leave the connection hanging.

Yes, I agree as firewall is completely disabled on the mac and the tcpdump shows it never attempts the outbound connection at all. In fact, it doesn't even do the DNS lookup.

> And the ssh connection did not get far enough to exchange any keys, so at the moment they are not an issue.

Yes, obviously key exchange it's relevant if the two sides aren't connecting.

> I would suggest going to the remoteserver.com and look at the sshd log entries. I would look in /var/log and

It's not even leaving the client, must less reaching the remote server.

Boot in to Safe mode

Boot macOS Safe Mode: https://support.apple.com/guide/mac-help/start-up-your-mac-in-safe-mode-mh21245/mac

See if ssh works there.


If you have a $HOME/.ssh/config file, rename it so it is not used (as an experiment), and try to make an ssh connection.


Create a new user account (System Preferences -> Users & Groups), and see if you can ssh from the new user account.


Move your Mac to a new location. If at work, take it home. If a home, take it to work. Can you ssh to other systems without problems at the new location?


If all else fails, declare defeat, and give up using ssh.


EtreSoft and I both know that ssh works. The thousands of other employees in my company using Macs, also know ssh works. I've used ssh in many different situations, and environments, both to local LAN systems, systems across the company I work for, across VPN connections, across the Internet, tunneled through the corporate firewall, via Carbon Copy Cloner across the internet backing up my Mom's iMac, etc.... Tons of different situations, and it has been solid and reliable.

Similar questions

11 replies
Question marked as Top-ranking reply

Nov 14, 2023 2:28 PM in response to johnnylingo

johnnylingo wrote:

> This would imply the remote system is not responding to your ssh request.

Or it could also imply the local system (the mac) never attempted the outbound connection

No. If the local system could not make the connection, it would have come back immediately. It would not hang.


ssh works on Mac, and has been working since the Mac OS X releases back in the early 2000's. I've been personally using ssh on my Mac everyday, all day, since 2005 as part of my day job.

> I assume if you leave the request long enough, it times out.

No, there is no error message or timeout because the client never attempted the outbound connection
> macOS is attempting to connect, but not getting a response.

No, it's not attempting to connect at all, as demonstrated by running tcpdump -i en0 -n port 22

Have you tried that tcpdump command on a working ssh connection to make sure all the options are correct?


On my Mac I see:

debug1: Connecting to development.system.mycompany.com [nn.nn.nn.nn] port 22.

debug1: Connection established.


Is this the /usr/bin/ssh version? I just want to insure that a different ssh version was installed./usr/bin/ssh

> This also implies that remoteserver.com port 22 is open, as a closed port would return immediately.

Yes, closed ports typically show 'connection refused' or similar

> It also implies that there is a process listening on port 22, but not responding, otherwise the port would not be open.

Yes, there is of course, as I can connect to it fine running nc, and packet captures on the remote end confirm that.

> I do not think this is a firewall issue on either system, as a firewall blocking the connection would just reject the connection request, not leave the connection hanging.

Yes, I agree as firewall is completely disabled on the mac and the tcpdump shows it never attempts the outbound connection at all. In fact, it doesn't even do the DNS lookup.

> And the ssh connection did not get far enough to exchange any keys, so at the moment they are not an issue.

Yes, obviously key exchange it's relevant if the two sides aren't connecting.

> I would suggest going to the remoteserver.com and look at the sshd log entries. I would look in /var/log and

It's not even leaving the client, must less reaching the remote server.

Boot in to Safe mode

Boot macOS Safe Mode: https://support.apple.com/guide/mac-help/start-up-your-mac-in-safe-mode-mh21245/mac

See if ssh works there.


If you have a $HOME/.ssh/config file, rename it so it is not used (as an experiment), and try to make an ssh connection.


Create a new user account (System Preferences -> Users & Groups), and see if you can ssh from the new user account.


Move your Mac to a new location. If at work, take it home. If a home, take it to work. Can you ssh to other systems without problems at the new location?


If all else fails, declare defeat, and give up using ssh.


EtreSoft and I both know that ssh works. The thousands of other employees in my company using Macs, also know ssh works. I've used ssh in many different situations, and environments, both to local LAN systems, systems across the company I work for, across VPN connections, across the Internet, tunneled through the corporate firewall, via Carbon Copy Cloner across the internet backing up my Mom's iMac, etc.... Tons of different situations, and it has been solid and reliable.

Nov 9, 2023 5:16 AM in response to johnnylingo

Have you tried

ssh -v -v -v user@remote.system.address


and comparing the output against a working connection.



Also, OpenSSH starting in Ventura, depreciates RSAkeys. This includes ssh host keys. If you are really still on Monterey, then RSA keys are still allowed.


HOWEVER, if your remote system has the more recent OpenSSH version, then it will be blocking your Monterey based RSA host keys.


NOTE: I have used ssh across the Internet lots of times. I used to do it to my Mom’s iMac in order to do nightly backups, and remote support. I do it with my own system when I’m out of the house.


The biggest road blocks are home routers not being setup to port forward the ssh connection, and firewalls either on the source or destination system.


For example, things like local 3rd party anti-virus packages can block ssh connections that are not to local LAN addresses. Little-Snitch can also block non-LAN ssh traffic.


And these 3rd party apps can go the other way and block incoming connections that are not from the local LAN.


macOS can also be configured to only accept incoming ssh connections from specific users (Sharing -> Remote Login)

Nov 9, 2023 5:27 AM in response to johnnylingo

johnnylingo wrote:

I noticed I can't start a CLI (Terminal, for the sake of this audience) SSH session

You needn't worry about the technical knowledge of your audience

I know the port 22 traffic is permitted on both firewalls based on the following evidence:

The firewall doesn't matter for outgoing connections. You should probably double-check other types of "security" apps that you have installed. Many are outright scams. Some are designed for software piracy. Others will just randomly break things. It makes it very difficult for us to help because we don't use that software and our ssh connection works just fine.

2) Connecting from behind the same Public IP from a Windows PC running Xterm, the SSH session works fine

Maybe double-check exactly what you are doing here. Windows doesn't run xterm, at least not in that way. You could use X on windows to run a remote connection via Xterm, but then you would just be making a location connection since you are already in an xterm session on the server.

Also interesting: if I'm behind the same firewall as the SSH server and access it via a carrier-grade NAT (100.64.0.0/10) IP address, connection is OK.

Are you saying that you are using a Mac on the same network as the server?

My hunch here is there's a security setting in MacOS that dis-allows SSH connections via Internet.

That is not a successful hypothesis. SSH connections via the internet work just fine on macOS.


Nov 9, 2023 8:33 AM in response to etresoft

> Also, OpenSSH starting in Ventura, depreciates RSAkeys


The tcpdump shows quite clearly that the connection isn't even being attempted. This has nothing to do with keys, passwords, or anything else related to authentication.


> You should probably double-check other types of "security" apps that you have installed. Many are outright scams.


I work in IT, so obviously I know better than that. There's two VPN clients installed: Palo Alto Global Protect and FortiClient VPN. But these are simple VPN clients; they don't do any other security services. But I might try un-un-installing them anyway.


> Windows doesn't run xterm


Sorry I meant "XShell", not xterm (which is Linux)


> Are you saying that you are using a Mac on the same network as the server?


Not same network, but behind same firewall (Mac is on LAN, SSH server is on DMZ)


> SSH connections via the internet work just fine on macOS.


Yet here's a thread with the exact same issue: https://apple.stackexchange.com/questions/428455/outbound-ssh-times-out-while-telnet-to-the-port-22-works

Nov 9, 2023 9:01 AM in response to johnnylingo

johnnylingo wrote:

Yet here's a thread with the exact same issue: https://apple.stackexchange.com/questions/428455/outbound-ssh-times-out-while-telnet-to-the-port-22-works

The exact same issue? How do you know that? OK. Fine. I won't dispute it.


First of all, you should probably upgrade from Big Sur. At least update from 11.6. The current version of Big Sur is 11.7.10.


Next, you said that telnet works. How is that even possible? Telnet was removed from macOS in version 10.13 "High Sierra" circa 2017.


Hopefully, at this point, you will agree that this might not be the exact same issue. 😄 But maybe you're wrong. Maybe it is the same issue, after all. One way to get Telnet installed is using Homebrew. Have you installed Homebrew or anything like it? Pretty much whenever someone posts about a problem with really basic command-line operations, Homebrew inevitably rears its ugly head.


If you have installed Homebrew, that's going to be a mess to fix. I normally just tell people to erase the hard drive and reinstall. I can't even use the caveat about restoring only user files and user accounts because those could be scrambled by Homebrew too. These tools are pushed to people with beginner-level skills but require very advanced knowledge to remove. If you work in IT, maybe you can successfully uninstall it.


If you haven't installed Homebrew, then I don't know what to tell you. Maybe try booting in Safe Mode? See Start up your Mac in safe mode - Apple Support


The claim that ssh simply doesn't work is a non-starter. Lots of people, including myself, use it multiple times a day and have for many, many years.

Nov 9, 2023 7:52 PM in response to johnnylingo

johnnylingo wrote:

my-macbook-pro:~ me$ ssh -vvv remoteserver.com
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/me/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->
'/Users/me/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' ->
'/Users/me/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to remoteserver.com port 22.

This would imply the remote system is not responding to your ssh request.


I assume if you leave the request long enough, it times out.


macOS is attempting to connect, but not getting a response.


This also implies that remoteserver.com port 22 is open, as a closed port would return immediately.


It also implies that there is a process listening on port 22, but not responding, otherwise the port would not be open.


I do not think this is a firewall issue on either system, as a firewall blocking the connection would just reject the connection request, not leave the connection hanging.


And the ssh connection did not get far enough to exchange any keys, so at the moment they are not an issue.


I would suggest going to the remoteserver.com and look at the sshd log entries. I would look in /var/log and

grep sshd *.log

And see if you can find any connection requests from your Mac.


Also in remoteserver.com you might want to do

sudo lsof 

And look to see what process is listening on port 22.

Nov 9, 2023 8:34 AM in response to BobHarris

my-macbook-pro:~ me$ ssh -vvv remoteserver.com
OpenSSH_8.6p1, LibreSSL 3.3.6
debug1: Reading configuration data /Users/me/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files
debug1: /etc/ssh/ssh_config line 54: Applying options for *
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' ->   
'/Users/me/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> 
'/Users/me/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to remoteserver.com port 22.


Nov 14, 2023 8:43 AM in response to BobHarris

> This would imply the remote system is not responding to your ssh request.


Or it could also imply the local system (the mac) never attempted the outbound connection


> I assume if you leave the request long enough, it times out.


No, there is no error message or timeout because the client never attempted the outbound connection


> macOS is attempting to connect, but not getting a response.


No, it's not attempting to connect at all, as demonstrated by running tcpdump -i en0 -n port 22


> This also implies that remoteserver.com port 22 is open, as a closed port would return immediately.


Yes, closed ports typically show 'connection refused' or similar


> It also implies that there is a process listening on port 22, but not responding, otherwise the port would not be open.


Yes, there is of course, as I can connect to it fine running nc, and packet captures on the remote end confirm that.


> I do not think this is a firewall issue on either system, as a firewall blocking the connection would just reject the connection request, not leave the connection hanging.


Yes, I agree as firewall is completely disabled on the mac and the tcpdump shows it never attempts the outbound connection at all. In fact, it doesn't even do the DNS lookup.


> And the ssh connection did not get far enough to exchange any keys, so at the moment they are not an issue.


Yes, obviously key exchange it's relevant if the two sides aren't connecting.


> I would suggest going to the remoteserver.com and look at the sshd log entries. I would look in /var/log and


It's not even leaving the client, must less reaching the remote server.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Can't SSH to host via Internet, but connectivity is allow and working

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.