Jun 24 11:02:37 xxxx systemd[1]: Starting ssh.service - OpenBSD Secure Shell server...
Jun 24 11:02:37 xxxx sshd[231251]: error: Bind to port 22 on xxx.xxx.xxx.xxx failed: Cannot assign requested address.
Jun 24 11:02:37 xxxx sshd[231251]: fatal: Cannot bind any address.
Jun 24 11:02:37 xxxx systemd[1]: ssh.service: Main process exited, code=exited, status=255/EXCEPTION
Jun 24 11:02:37 xxxx systemd[1]: ssh.service: Failed with result 'exit-code'.
Jun 24 11:02:37 xxxx systemd[1]: Failed to start ssh.service - OpenBSD Secure Shell server.
Only if you understand the implications of doing that. You’ll need to rebuild the firewall, reconfigure it for all of the services Virtualmin needs, reconfigure fail2ban to work with it instead, etc. That seems like a tremendous amount of work to avoid creating one rich rule in firewalld.
Oh, crap. Nevermind. I see what you’re saying, and I guess the SSH Server module doesn’t allow creating IP-based access control. I’ve never used it, I had no idea, I just assumed it did. I have no idea why it wouldn’t.
I guess you’ll need to edit the sshd_config directly. I’ve never done what you’re trying to do (i just require key-based auth, disable password auth, and disallow root logins, I don’t try to micromanage IPs and risk locking myself out), but I assume a Match Address section can do what you want.
But, I think you should just use key-based authentication, protect your key with a passphrase, and disable root logins (making sure you have sudoers configured appropriately). That’s going to be as secure as, or possibly more secure than, a firewall rule or an IP-based restriction.
What do you think my rule does? service name=“ssh” is just a human readable way of saying port 22 and the IP range can be any range including real world IPs or it can be a single IP.
Unfortunately Virtualmin doesn’t deal with creating rich rules, so you need to do it manually.
You should wrap any code/commands in backticks or triple backticks (or click the “Preformatted text” button in the editor window), so that quotes and other things don’t get messed up. If OP tried copy-pasting this example, it wouldn’t work because the magic quotes are invalid syntax.
Knowing you are connecting from a remote IP keep in mind some things.
Most ISP’s are dynamic meaning they change your external IP the one you will need to add from time to time.
What this means for you is there could be circumstances where your ISP gives you a new IP and you will forever be locked out of access so you’ll have to save a backup of your virtualmin a full backup without any restrictions so that you can upload and easily restore your server configuration.
You could limit this type of failure by looking up the ASN’s for your ISP and adding them to the white list. Alternatively, you could use a static IP VPN host quite possibly. If your ISP is a big name you’ll likely not want to add ASN’s because you’ll be allowing far to many people access. But it will greatly limit the scope of who can login adding ASN’s while not ideal security. Most hackers use VPN connections or non ISP direct connections.
But at the end of the day if you don’t have a static IP plan for failure to login at some point in case of some random turn of events where the ISP no longer has your static IP or your VPN no longer has that specific static IP etc… While it shouldn’t happen sometimes it does.
I assume you already know this but others may not and I feel it’s an important thing not to leave out.
If you have another server you could log in using ssh from there, the ip for that should be static. But not everyone has a second server, but it doesn’t take much to run up a server login to the old server change the firewall rule
Yes “Should Be” in a perfect world I was just iterating to plan for the worst things do change at times (though rare) you learn some lessons in the cross that bridge when you get there type of approach one of the most important lessons is always have a planB. I’ve delt with smaller up and coming companies, hosts, and VPN providers and things do change I recall being locked out of login because of restrictions. Or sometimes the host went belly up after paying for several years of service on this “Deal Price” Other times they got hacked remember when this happened to 1and1 I think it was well lets just say it was messy had to start from scratch. Didn’t plan for the worst they had taken backups but for whatever reasons upon restoration my backups were not even there so if you can store backups locally.
jimr1 Great addition yes!
Good thing that I left out was this yes also true one could do it this way.
I was just iterating to plan for the worst things do change at times (though rare) you learn some lessons in the cross that bridge when you get there type of approach one of the most important lessons is always have a planB. I’ve delt with smaller up and coming companies, hosts, and VPN providers and things do change I recall being locked out of login because of restrictions. Or sometimes the host went belly up after paying for several years of service on this “Deal Price” Other times they got hacked remember when this happened to 1and1 I think it was well lets just say it was messy had to start from scratch. Didn’t plan for the worst they had taken backups but for whatever reasons upon restoration my backups were not even there so if you can store backups locally.