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
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.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
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.* - 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
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
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.
systemctl status ssh.service also advised
Deprecated option for the following
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.
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!