SSH from internet

Help and Support Raspberry Pi
1

I have a custom WOL script on my pi. Have always been able to log in over internet via ssh (port forwarded in router) to run script, but just recently am able to log in fine when on own WiFi, but trying to do this via the internet has stopped working. Checked router and correct port/ rule is still set up

Any ideas where to start with troubleshooting this?

2

You should check the system journal for details of any SSH logon attempts:

sudo journalctl

If you can log on from the internet while still being able to monitor the system journal, eg by going out via a VPN, you can see in real time what’s happening with

sudo journalctl -f
3

DHCP lease expire and your ISP changed your external IP address?

I do this regularly myself and I run a cron job where my OSMC box checks it’s external IP address and pushes it to a place I can access. I have a script that reads that and kicks off ssh to the appropriate IP and port.

4

Thanks both for your suggestions.

IP is fine, log in via a no-ip address.

Strange thing - reckon phone proivder has blocked the traffic - if I fire up a VPN on my phone and then try to log in, everything fine, turn it off, no connection whatsoever to the pi (used journalctl -f to check).

Not ideal, but a work around!

5

Does this indicates that you are port forwarding 22 to the web?

6

So you think that this might be an outbound issue, with your mobile phone company, rather than an inbound one? They do have a habit of doing hinky things with traffic. I guess you should be thankful the VPN is still getting through.

7

Yep, guessing phone company are blocking traffic on port 22 now

8

They tend to have a downer on UDP traffic but TCP usually gets through. I’d be inclined to try different incoming ports on your router. You can forward them to port 22 (or wherever) in the router. In fact, I’d always recommend you use a different Internet-facing port than 22 for SSH.

9

Thatt’s why I run my externally facing SSH port on 443 on my router, forwarded to 22 on my OSMC. Unless they white it, it wont be blocked.

EDIT: And you can set up a SOCKS5 proxy with -D and use FoxyProxy on Firefix to get all browser traffic through it.

10

This is literally a worst practice and I’d say you are lucky it’s blocked. You would have certainly been being probed by script kiddies and botnet operators if traffic were allowed to pass on 22. Even if they didn’t get access, it’s still costing CPU cycles to refuse their attempts.

You should always forward some non-standard port from outside your firewall to 22 on the lan side, or change the ssh all together to some non-standard port.

11

@ActionA, yes. It’s easy to scan all ports and even easier to tell the port is running SSH. telnet to an ssh port; it announces itself. But also, as in my case, sometimes all ports are locked down except specific ones. No one can lock down 443 without a rather large whitelist of exceptions though. It’s possible, but unlikely. So I run SSH on 443.

12

Changed ssh to use some random port and tried again, same result, could connect on 4g via vpn, but not without the vpn.

Just as a test, installed a different ssh app, and everything works over 4g! App must have have an update that broke it, although why it would only not work over 4g is beyond me!

Thanks for everyone’s time on this - not an osmc issue at all

13

Securing ssh isn’t hard, but it does take a few steps.

  1. Always, always, use ssh-keys, NEVER passwords.
  2. NEVER allow remote root access.
  3. Block all IPs that don’t have any business getting ssh access, if you can. That means allowing your work public IPs when you want to ssh home, or your home IPs when you want to ssh into work. Don’t allow the entire USA, Europe, Russia, China, Japan, Mexico, if you live in Chile. Only allow Chilean IPs to even make an attempt. Realize that Geo-IP lists are flawed, not 100% correct, and change constantly.
  4. Don’t allow constant attack attempts. Block an IP/subnet after 3 failed attempts for a day (or a week).
  5. It used to be that moving the sshd to a non-standard port (router port translation) was sufficient to avoid 99.99999% of the issues. In the last month, I’ve seen 1000+ attempts against my high-port SSHd listeners. That makes the firewall blocks critical.
  6. Use either fail2ban or denyhosts to dynamically block failed attackers. I cannot think of any reason NOT to install fail2ban at the same time I install openssh-server.
  7. Stay patched with any internet-facing devices. Weekly is a good idea. Monthly is a little lacking. Quarterly is unacceptable.

Of course, there are exceptions to these items. Thankfully, ssh and iptables allow highly locked down situations, but they aren’t for noobs.

For remote access into your LAN from anywhere, really only 443/tcp will work almost always. Some corporate/nation-state level firewalls DO know the difference between ssh traffic and HTTPS traffic, but most do not.
If you want remote access into an OSMC/Kodi/Plex setup, you can use SOCKS over ssh and a web browser. I use this all the time from different continents. Of course, the internet connection much support the required bandwidth. Internet in the middle of nowhere in Patagonia just doesn’t support video streaming … but it did work fine for audio. Tested 2 weeks ago. :wink: YMMV. I’ve done video from Europe, SE-Asia, Central America and South Africa sourced from the USA. Just had to turn down the 1080p to 480p video.

If you need more details, ask. I don’t use ssh much from phones or android devices. Still ssh is pretty amazing.

14

Nice post but I think it would be helpful if you would have mentioned more details for the different steps.
Eg

How to achieve?

Also

I still believe openvpn on 443 is more powerful

15

openvpn is more hassle. ssh is trivial in comparison. I know people who spend weeks trying to get openvpn working, some never do, but 10 minutes for ssh.

True, openvpn is capable of many things, but for many common uses, ssh is just as capable. ssh and sftp and rsync are extremely powerful. Between those 3 options, which you get by setting up openssh-server, the only real limitation is using protocols that have ZERO security and expecting them to be secure from devices which cannot be secured anyway (Windows, Android, iOS).

How to block attempts - I listed 3 methods. fail2ban, denyhosts and iptables. Block most of the internet with iptables. Actually, I’d use ipset (it is more efficient loading large rules). Fail2ban watches all remaining connections for failures. It is highly configurable, but still fairly easy to use. The defaults secure sshd on port 22 by default. There are multiple manpages which explain more.

You Don't Know SSH About ssh | JDPFu.com 2023 has more details.