I'm trying to connect via ssh to my home server from outside of my home network, but I don't get any respond.

When I try to locally ssh that server, everything is just fine.

But when I do it from outside, server is not responding:

  • I have public dynamic IP and no-ip DDNS name.
  • I am accessing ssh through port 5001
  • On my router I set port forwarding from 5001 to 22 and to ip of my server (
  • Dumping the network with tshark I can see incoming SSH packets to server ip (source ip is the ip of my router, my public ip), but there is no response from server.

This makes me think, that there is some filter set for public IPs. UFW is set to allow 22 port.

May the fault be in sshd_config??

The only uncommented lines in sshd_config are:

  • Include /etc/ssh/sshd_config.d/*.conf #there is no file in sshd_config.d
  • ChallengeResponseAuthentication no
  • UsePAM yes
  • X11Forwarding yes
  • PrintMotd no
  • AcceptEnv LANG LC_*
  • Subsystem sftp /usr/lib/openssh/sftp-server

Any suggestions? :)

EDIT: (Trying to get some more info)

sobik@Sobik-MacBook-Pro ~ % ssh -v -p 5001 sobikk@myip.hopto.org
OpenSSH_8.6p1, LibreSSL 2.8.3
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 *
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to myip.hopto.org port 5001.'

and then.. timeout

And with sudo iptables -L -v -n | grep :22 I get:

30 1976 ACCEPT tcp -- * * tcp dpt:22

  • to see if ufw is the issue, disable it temporarily
    – Bravo
    Nov 24, 2021 at 0:23
  • @Bravo Actually, I installed UFW after the problem had occurred. With no UFW there was same issue. Nov 24, 2021 at 0:30
  • Increase verbosity on the ssh client side by adding one or more -v options, this will give you more info on what is happening at various stages in the ssh connection attempt. Also check your logs on the sshd server. On Debian, ssh connection attempts are logged in /var/log/auth.log by default.
    – cas
    Nov 24, 2021 at 0:47
  • Also, you can check if there are any firewall rules blocking port 22 on your server by running sudo iptables -L -v -n | grep :22
    – cas
    Nov 24, 2021 at 0:51
  • The ACCEPT rule is fine. It's explicitly allowing ssh connections from anywhere. And it has seen 30 packets totalling 1976 bytes matching that rule so far. Try adding more -v options to the ssh command for more verbosity (maximum verbosity level is 3).
    – cas
    Nov 24, 2021 at 3:22

1 Answer 1


Things to check:

  • Debian 11 is beginning the transition from iptables to nftables, so in addition to iptables -L -vn, also check nft list ruleset.
  • Debian's sshd uses libwrap.so, so the contents of /etc/hosts.deny and /etc/hosts.allow will also have an effect on which connections will be allowed and which won't be. If you want to allow incoming SSH connections from anywhere, make sure /etc/hosts.allow has a line sshd: ALL in it.
  • on the server side, check grep sshd /var/log/auth.log and journalctl _SYSTEMD_UNIT=sshd.service.
  • There is no transition from iptables to netfilter because both iptables and nftables are part of Netfilter. There is a transition from iptables to nftables/nft. Nov 24, 2021 at 3:32
  • @HaukeLaging I got the two mixed up (insufficient caffeine error). Edited.
    – telcoM
    Nov 24, 2021 at 7:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.