2

I am a beginner and new to development boards and Linux as a whole, and have been using the wonderful SSH package with Debian (I believe this is OpenSSH) to tinker around and learn more without the need to be physically connected to my Pi through a serial cable.

I have followed various websites and threads on this forum to harden and tweak my SSH to be more secure. An important change I'd like to make to my sshd_config file has vexed me however - ListenAddress. As I understand it, the ListenAddress value in sshd_config defines the strict parameter of IP address(es) the server should listen to requests from.

The default value for ListenAddress in sshd_config is 0.0.0.0, which is commented out. I understand that working on a "commented out defaults" policy, the application will default to this value. I've read the Man[ual] Page which indicates the default is to

listen on all local addresses on the current routing domain

and while I can't profess to know a lot about networking, I've read elsewhere 0.0.0.0 indicates the server will listen for requests from any IPv4 address from the internet at large? I am worried this may make my (internet facing) Pi a target for attack, and it seems prudent to limit ListenAddress to only listen for requests from my internal network. I won't have need for access anywhere other than home.

My router (Apple Airport) DHCP Range is 10.0.1.2 to 10.0.1.200, with the router at 10.0.1.1. (This seems to be the default, if I had known more perhaps I should have changed this to 192.168.1.1). I have tried setting the following ListenAddress values, all of which have locked me out of SSH, necessitating connecting with a USB serial cable to revert ListenAddress back to default:

10.0.1.0 - I thought setting the last octet at 0 may indicate all IPs on the 10.0.1. range

10.0.1.* - I thought using * as a wildcard may work as per the first example as above

10.0.1.** - In case the single * wildcard only indicated a .1 to .9 range

10.0.1.1 - It seems silly now but I thought setting the router's IP may do the trick, as this is the magic 'box' handing out the IP addresses

10.0.1.1/24 - Using /24 to define the first three octets, leaving the last octet as the open 'range'. But it seems sshd_config doesn't recognise the / character

127.0.0.1 - I learned about the localhost or loop back address option, but this didn't work either

10.0.1.24 - My computer's IP. This last throw of the dice didn't work, and on running systemctl status ssh.service returned error: Bind to port 22 on 10.0.1.24 failed: Cannot assign requested address, fatal: Cannot bind any address and Failed to start OpenBSD Secure Shell server messages.

I hope this goes some way to explaining my thinking, and what I've tried so far - I feel I've exhausted all logical options and perhaps 0.0.0.0 is the only permitted option for what I am trying to achieve. Do let me know if my question is better suited to the networking forum instead.

Worryingly, systemctl status ssh.service also advised Deprecated option for the following sshd_config values:

Deprecated option KeyRegenerationInterval
Deprecated option RhostsRSAAuthentication
Deprecated option RSAAuthentication
Deprecated option KeyRegenerationInterval
Deprecated option RhostsRSAAuthentication
Deprecated option RSAAuthentication

However I'm at a loss as to what the program's favoured values for these should be.

I am pushing the limits of my (very limited) knowledge thus far, but I understand from my previous query to this board plenitude and prolixity is encouraged to assist your kind replies.

My sshd_config defaults are v1.103 and the changes I have made are:

AddressFamily inet
AllowUsers keith
Protocol 2
LoginGraceTime 30
KeyRegenerationInterval 3600
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 1
PubkeyAuthentication yes
IgnoreUserKnownHosts yes
IgnoreRhosts yes
RhostsRSAAuthentication no
RSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
AuthenticationMethods publickey keyboard-interactive
UsePAM yes
X11Forwarding no
PrintMotd no
TCPKeepAlive no
ClientAliveInterval 360
ClientAliveCountMax 0

I have been using a variety of websites and sources for guidance, so some of these values may now be superannuated. I understand SSH security is constantly evolving and something of a moveable feast.

I hope this explains my thought process and methodology, and my apologies for the lack of brevity. Thank you all for your kind help thus far, it is very much appreciated. Never stop learning!

2

The ListenAddress is actually telling which system interface the SSH server should listen on (0:0:0:0 makes it listen to all interfaces). For instance if your system has a Wifi (on 10.0.1.4) and an Ethernet (10.0.1.12), ListenAddress 10.0.1.12 will make it listen only on the Ethernet interface, and other computers will have to SSH to 10.0.1.12 to get a connection.

To restrict external users to a given range of addresses, you can use a firewall, either iptables directly (but it isn't fit for mere humans) or a more palatable front-end such as ufw.

However, since you are behind a router, the router may already block external accesses, systems on the other side of the router do not see your 10.0.1.* adress, for them everything comes from a single address: your router, and to initiate connections from outside to one of your local machines the router would have to be set to perform port-forwarding (connections to some specified port on the router are forwarded to a specific local address:port on your local network).

7
  • Thank you for your answer, I think I understand now. I thought ListenAddress meant listening for the range of clients trying to connect to the Pi, rather than setting to the IP of the Pi itself. I've set ListenAddress to the IP of the Pi and restarted ssh.service, and it hasn't locked me out of SSH, so it is looking good. I have DHCP and NAT enabled at the router and port forwarding isn't enabled, so it must be as you say that the router is blocking external accesses as a first line of defence. I read iptables and IP Wrappers are effective so I'll read more into this, thank you. – Keith Savage Jun 8 '20 at 16:42
  • If the answer is good, please consider accepting it. Also ufw is much easier to use than iptables (it is still iptables under the hood). There are even GUI front-ends (gufw). – xenoid Jun 8 '20 at 21:35
  • Thank you. I'm still reading up on iptables and ufw - it is definitely a bit more advanced than my current level but the more I am reading, the more I am understanding! Unfortunately I'm no longer able to SSH into my Pi, after setting ListenAddress to its IP I am now getting the error ssh: connect to host [Pi IP] port [#]: Connection refused. I'll use my serial cable to set ListenAddress back to 0.0.0.0 but I'm still at a loss as to what I may be doing wrong? Thank you for your advice and assistance thus far. – Keith Savage Jun 9 '20 at 17:54
  • What address are you using? 127.0.0.1? – xenoid Jun 9 '20 at 19:34
  • For ListenAddress I set this to the IP of the Pi, which locked me out of SSH. I used my serial jumper cable to change ListenAddress back to 0.0.0.0, and I can SSH in again now. I tried setting ListenAddress to 127.0.0.1 previously, which also locked me out of SSH (I then serial'ed back in to revert to 0.0.0.0 to get SSH access back). I'm using the 10.0.1.* range - I believe this is an Apple router default unfortunately. If I'd known then what I know now I would have set this to 192.168.*.*! – Keith Savage Jun 10 '20 at 11:28
2

iptables way (man page)

I'd advise to allow local only network to your machine via iptables, as I'm doing it this way:


Example such rule taken from my rules.v4

long version

--append INPUT --protocol tcp --match tcp --destination-port 22 --match iprange --src-range 192.168.0.2-192.168.0.254 --match comment --comment "ssh + sshfs" --jump ACCEPT

short version

-A INPUT -p tcp -m tcp --dport 22 -m iprange --src-range 192.168.0.2-192.168.0.254 -m comment --comment "ssh + sshfs" -j ACCEPT

Modified example using conntrack + specifying subnet

long version

--append INPUT --match conntrack --ctstate NEW,ESTABLISHED --protocol tcp --match tcp --destination-port 22 --source 192.168.0.0/24 --match comment --comment ssh --jump ACCEPT

short version

-A INPUT -s 192.168.0.0/24 -p tcp -m conntrack --ctstate NEW,ESTABLISHED -m tcp --dport 22 -m comment --comment ssh -j ACCEPT
0

You can keep everything in ssh by using the "Match" directive in your sshd_config

# This will disallow everyone
AuthorizedKeysFile /dev/null
# Put the netmask you want to allow here
Match Address 10.0.1.1/24
# Connections from above IP can use normal authorized keys to authenticate
AuthorizedKeysFile %h/.ssh/authorized_keys

Best to test from the console to prevent accidentally locking yourself.

2
  • Thank you for your answer. Unfortunately I'm still getting the error ssh: connect to host [Pi Hole IP] port [Pi Hole Port]: Connection refused. I've set the IP range to my network, so it reads Match Address 10.0.1.0/24. The text shows a different colour (green) for Address, however is showing the expected colour (red) for the 10.0.1.0/24, part, however the / is showing black. This may be indicating an error of some sort with the use of the forward slash. I don't believe I'll be able to get Match to work - I'm unsure if this is because of Debian or my 10.0.1.* IP range. – Keith Savage Jun 11 '20 at 18:23
  • You can troubleshoot by first stopping SSH sudo service ssh stop and then running in debug mode with sudo service ssh start -d. This will give you a dump of debug messages to help diagnose the login. Key things to look for "Connection from xxxx" to verify the IP that SSH is seeing the connections coming from. I would start out by banning everyone and verifying that works and then with the IP info above try to allow that one IP only (that is, don't use the netmask slash part yet) and see if it works. – Kelly Trinh Jun 12 '20 at 3:55

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.