5

Ok, maybe I'm weird or something, but I can't figure this one out. MacOS Mojave, native IPv6 from my ISP.

As you can see, sshd is listening on both v4 and v6:

alluminium:~ root# netstat -an | grep 22 | grep LISTEN
tcp4       0      0  *.22                   *.*                    LISTEN
tcp6       0      0  *.22                   *.*                    LISTEN

Local connection on non-loopback interface over v4 works perfectly:

alluminium:~ root# nc -w1 -z -v 192.168.2.12 22
found 0 associations
found 1 connections:
     1: flags=82<CONNECTED,PREFERRED>
    outif lo0
    src 192.168.2.12 port 59078
    dst 192.168.2.12 port 22
    rank info not available
    TCP aux info available

Connection to 192.168.2.12 port 22 [tcp/ssh] succeeded!

Now, when I try remote, on v6 it works:

root@keeper:~# ssh alluminium -v
OpenSSH_7.4p1, OpenSSL 1.0.2r-fips  26 Feb 2019
debug1: Connecting to alluminium [2001:985:4xxxxxxx:d585] port 22.
debug1: Connection established.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'alluminium,2001:985:4xxxxxx:d585' (ECDSA) to the list of known hosts.

debug1: Next authentication method: keyboard-interactive
Password:

However, v4 just times out:

root@keeper:~# ssh 192.168.2.12 -v
OpenSSH_7.4p1, OpenSSL 1.0.2r-fips  26 Feb 2019
debug1: Connecting to 192.168.2.12 [192.168.2.12] port 22.

I have checkpoint endpoint security installed, thought it might get in the way, shut down all its components, PF rules don't show anything either.. Nothing.

I feel totally stupid now :) Any suggestions are much appreciated.

3
  • A few questions: Why do you use netcat instead of ssh to demonstrate local connection? Can you connect to other TCP ports over IPv4? Do you have any non-default configuration in /etc/ssh/sshd_config? Do you use fail2ban?
    – bot47
    Commented Aug 14, 2019 at 6:58
  • Also, as an addition, I suggest you put all ssh command line parameters first and after that the destination address, as this might be confused with commands to on the ssh server.
    – bot47
    Commented Aug 14, 2019 at 7:00
  • Thanks for your suggestions! I use netcat cause the connection fails on TCP level, not on SSH protocol level, hence port availability demonstration should be sufficient. I don't use non-standard config in ssh configuration, I don't have anything else listening on the machine globally other than SSH, but I could try and emulate it with netcat to test. I don't use fail2ban. Parameters to SSH in this case aren't confused, it's a POSIX-compliant command, as you can see it enters verbose mode. :)
    – favoretti
    Commented Aug 14, 2019 at 7:21

1 Answer 1

5

Right.. I finally figured it out.

It still was the damned Checkpoint Endpoint Security VPN client. Apparently it installs a kernel extension com.checkpoint.cpfw that the service com.checkpoint.epc.service controls according to organizational policy. In my case it was dropping all incoming connections. Shutting down service doesn't flush the rules enforced by the kernel extension.

Unloading the kernel extension helped.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .