2

this is my first post on here so constructive criticism is appreciated.

target machine uname -a (the NAS itself):

Linux nas 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux

remote machine uname -a (the machine from which I'm attempting to access the NAS):

Linux tilly 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

The following aliases are used throughout the post:

LocalIPv4 - The local ipv4 address of the NAS assigned by the router (192.168.X.X).

WinLocalIPv4 - The local ipv4 address of a windows machine (accepting Remote Desktop connections) connected to the same router; this is the machine I used to test RDP (also 192.168.X.X).

PublicIPv4 - The public ipv4 address of the router

I'm setting up a NAS fileserver and have been having issues shelling into the machine via the internet. This isn't my first rodeo with ssh; I spent plenty of time trying, and failing, to fix it myself.

Locally, that is ssh localhost on the target machine works fine. Similarly, ssh LocalIPv4 from machines on the same network works fine. I have little experience manipulating Debian's firewall (ufw) so as far as I know it's been left default(See below for output of iptables -L).

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Pinging the router's PublicIPv4 works fine; here's the output:

PING PublicIPv4 (PublicIPv4) 56(84) bytes of data.
64 bytes from PublicIPv4: icmp_seq=1 ttl=63 time=5.08 ms
64 bytes from PublicIPv4: icmp_seq=2 ttl=63 time=3.59 ms
64 bytes from PublicIPv4: icmp_seq=3 ttl=63 time=11.4 ms
64 bytes from PublicIPv4: icmp_seq=4 ttl=63 time=13.6 ms
^C
--- PublicIPv4 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 3.589/8.424/13.592/4.194 ms

Port 22 has been forwarded to the correct machine in the router's settings. Here's the output of ssh -vvv PublicIPv4:

OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug2: resolve_canonicalize: hostname PublicIPv4 is address
debug2: ssh_connect_direct
debug1: Connecting to PublicIPv4 [PublicIPv4] port 22.
note from op: Hangs here with no timeout; I have to Ctrl+C out.

Here's the output of netstat -tlpn | grep 22:

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      17420/sshd          
tcp6       0      0 :::22                   :::*                    LISTEN      17420/sshd

Thinking it was an issue with the isp blocking certain ports, I tried switching to port 2222. With this port, ssh localhost -p 2222 from target machine and ssh LocalIPv4 -p 2222 from networked machine both work fine. However, the same issue when running ssh -vvv PublicIPv4 -p 2222.

I have also tried completely disabling the router's firewall, which was also default showing no obvious reasons why it would block port 22. I heard mention of some odd reverse DNS lookup issues and tried adding host rules in /etc/hosts on both machines to no avail.

In a desperate attempt, I tried accessing networked windows machines with RDP. I used rdesktop WinLocalIPv4 which also works fine, but, after forwarding the appropriate ports, even rdesktop PublicIPv4 hangs on a similar Connecting to . . . debug output line.

I've exhausted every option I know of as well as others that I have seen on this exchange. If there's any other information you would need to better inform your own troubleshooting/diagnosis I would be more than happy to provide. Thanks for the time.

EDIT:

After using a service called Shields Up!, it reported that the ports I had opened were operating in its "stealth mode". After disabling all obvious security features of my router, temporarily, the service still reported those ports as a "black hole for tcp packets". I'm almost certain this is the issue, but now the question is how do I actually open these ports? It seems as if disabling security features and port-forwarding are useless to that end. I'm considering opening a new question, but I'm not entirely sure where as this platform is new to me. Any advice on that front is appreciated.

EDIT 2:

After enabling connectivity logs on my router and running a probe of ports 0-1023, via Shields Up!, on my network, the connectivity logs report no incoming connections at all. The logs are working; there is plenty of outgoing https traffic. This definitely seems to be the issue, but I don't know how to stop this behavior. Where would I post a question like that?

Improve this question
12
  • You mention a target server, a remote server, and then a little later down, the server. Can you clarify which one's which, please. Which one owns PublicIPv4? Where does the router fit it, and is this a consumer grade device that does NAT too, or is it really just a router? Commented Aug 7, 2020 at 19:27
  • @roaima Right, sorry for the lack of clarity on that front. "Remote machine" is the laptop from which I'm attempting to access the NAS. "Target machine" is the NAS itself. The NAS and other home machines are connected to a single linksys router with, if memory serves, NAT support. The router owns PublicIPv4, and, in all cases except the RDP aside, LocalIPv4 is the local ipv4 address assigned to the NAS by the router. I'm not on-site and won't be for another 3 days, so, unfortunately, I am not able to confirm router NAT support. I will edit the question to be more clear, thanks. Commented Aug 7, 2020 at 20:19
  • 1
    @roaima Ahh, a few wiki pages later and, yes, the router definitely does NAT. The machines connected to it are all assigned 192.168.X.X addresses. I was ignorant to the fact that NAT was responsible for doing that. Commented Aug 7, 2020 at 20:36
  • Are you testing the PublicIPv4 connectivity from inside your own network? If so that may be the reason why it's not working - many consumer grade NAT devices can't handle "hairpin NAT" (internal network to external address that's mapped neck to a device on the same internal network) Commented Aug 7, 2020 at 22:07
  • Have you made any settings to the router to forward traffic? You need to instruct it to forward incoming ssh or rdp traffic from the Internet, destined to your public IP, to the NAT IP (the local IP) of your devices. Just disabling the router firewall is not enough. Commented Aug 7, 2020 at 22:13

3 Answers 3

Reset to default
1

This is more of a comment than an answer.

You can test to see if your router is properly forwarding ports to computers inside your LAN using Shields Up!.

I would highly suggest not opening/forwarding port 22 on your router. There are many people/botnets trying to brute-force their way into port 22. I would make your router Internet SSH port be higher than port 1024, a good router will let you map one port to an alternate destination port. (i.g. map your routers Internet port 9876 to port 22 of your SSH server.) People can still port scan your public IP to find an open port, however, they are probably only looking for common points of entry instead of scanning the entire 65535 port range.

Also, run fail2ban on your SSH server. If you change the port your LAN SSH server is on, you'll have to tell fail2ban which port to monitor as well because it defaults to monitoring port 22.

After running fail2ban for a day, look at its logs. You will probably see lots of IP's being banned because they are trying to get into your computer.

EDIT:

One caveat that I discovered on a router that I use... forwarding a single port does not seem to work on my router. However, I used a different way to get it working... I forwarded a range of ports.. with the start and end port being the same port number and that did work.

Also, read my answer to a similar question.

EDIT:

To prevent brute forcing passwords use these instructions to set up SSH Public Key Authentication.

After you do that, test to make sure that your public key works to login as root, then modify the config for sshd to disallow root login via password so that you can only login as root using your SSH public key. You can also use this method to login as a standard user using your SSH public key.

Also, as root or using sudo, lock the standard user account using the following command:

usermod -L username

This will disable logging in as that user using a password. However, your SSH public key will still work to login.

NOTE: When using the commands above remotely, open a new shell to the server to test your ability to login. This way, if you mess up and can't login, you are already logged into the other shell and can fix the problem.

Remember, test to make sure you can login with your account(s) using your SSH public key before you remove the ability to login using passwords.

Improve this answer
3
  • Great advice, albeit not an answer. I have disabled password authentication. Whether or not a pubkey is as prone to being brute forced as a password is a question for someone better versed in cryptography, but I would assume it's not. Regardless, more security is never a bad thing. Thanks for the advice. Commented Aug 10, 2020 at 14:03
  • So I was using that ShieldsUp service and it reports that the ports that I've opened for sshd are operating in "stealth" mode. Which is great in terms of security but I don't want these ports to be a "black hole for tcp packets". I've disabled the router's firewall and all the obvious security features of the router in it's settings and ShieldsUp still reports that these ports are operating in "stealth" mode. I am almost sure this is the problem, but I don't know how to actually open those ports (make them vulnerable in a sense). Is this material for another question, or can we keep it here? Commented Aug 10, 2020 at 14:58
  • You might try searching the brand and model of your router with "port forwarding" and maybe also "errors" or "problems." This might show issues other people have had with port forwarding. Also, in the config for sshd tell it to not allow root login unless it is with a public key. Commented Aug 14, 2020 at 1:06
0

It seems port forwarding is what you miss : it create (small) holes in your firewall.

Try learning a little from Linksys there. Make your changes at your router, and try accesses from the outside (for ex., with your laptop and a tethered 4G connection of your smartphone or free wifi). Take care that -as you said- sometimes ports are blocked (as from the outgoing side than from the incomming side...).

Enjoy !

Improve this answer
1
  • I'm very familiar with port forwarding, I mentioned in the post that I forwarded both port 22 and later, when I tried using port 2222, I changed the rule appropriately in my router's settings. While this is great advice, unfortunately it doesn't fix my issue. I'll edit the post to make it more clear that I did forward port 22, sorry about that. Commented Aug 8, 2020 at 16:48
0

I'm not sure for your router but you might check... for mine, when port forwarding, I can set "TCP", "UDP", and "TCP&UDP" ports, but for some reason, setting the "TCP&UDP" ports never works for me. I have to set both TCP and UDP for the same port to open both of them for the same (or different) machine.

for what it's worth, you probably already know this but you said "showing no obvious reasons why it would block port 22" so in response to that: not only are ports 0 through 1024 considered special and require root or special capabilities to reserve, but port 22 is usually reserved for SSH and so it is blocked by most home routers and default firewalls, and same for RDP; is reserved for 3389 usually also blocked by most home routers and firewalls. You can tunnel SSH connections from port to port to check if it is just a simple port issue.

Improve this answer
1
  • That's a great suggestion, thanks. When I get back on-site in a couple days I'll give that a try and report back how it goes. I am working with a new, unfamiliar-to-me router, so maybe that's a quirk that it has. When you say "tunneling SSH from port to port" do you mean configuring SSHD to listen on a different port, for example, say, port 2222? I did try that to no avail. Commented Aug 8, 2020 at 19:12

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.