Probably the most ubiquitous piece of software in use is OpenSSH. It is from the developers that also bring us that most secure OS, OpenBSD. We all use it, we all love it, we all depend on it. Please donate to these great projects if you can! And read on for the tips...
- Use an alternate port.
- This is more of an annoyance issue. Port 22 is a prime target for bots trying to gain entry into a system as it soon becomes clear when examining the logs on a publicly facing host. Sure, the firewall can block access based on repeated attempts but I find it simpler just to listen on a different port. Example sshd_config entry:
- Port 12345
- Don't allow the username "root" access.
- The one easily guessable username that will always be attempted by crackers is "root". Disallow this access. The sshd_config entry:
- PermitRootLogin no
- Use Protocol 2 only.
- Protocol 1 is considered weak and insecure. Protocol 2 is now the default on current implementations. The sshd_config entry:
- Protocol 2
- Limit logins by username.
- Besides blocking root access we can also limit logins to specific user names. If you're not on this list you don't get a chance. If root access to the host is needed be sure that the proper users are in the wheel group. Example sshd_config entry:
- AllowUsers lexluther loislane
- Use public-key-encryption.
- By using public-key encryption with a strong passphrase and denying password authentication your host is very safe. Many sites have instructions for setting this up and duplication here is unnecessary. Set up and test your public-key access before you turn off password authentication. The sshd_config entries:
- PubkeyAuthentication yes
- PasswordAuthentication no
- Use the "Match" feature to add more flexibility.
- Your host is now safe from the public side but you need access from various systems internally and conclude that password access is fine in this case as all of the other safeguards are still in place. In this case we'll use "Match" to override our "PasswordAuthentication no" directive when we connect from our internal network. Example sshd_config entry:
- Match Address 192.168.0.*
PasswordAuthentication yes - Make it easy to use public-key encryption with Keychain. Virtually every modern distro has this packaged and available.
- Make it easy to access your hosts on alternate ports with some edits to the ssh_config file.
- Your /etc/ssh/ssh_config file will have a default entry for host connections. Something like:
- Host *
AddressFamily inet
Port 22
Protocol 2
PreferredAuthentications publickey,keyboard-interactive,password - Simply add an entry above it for hosts that you want to treat differently. Example:
- Host host1 host 2 host3 host4
AddressFamily inet
Port 12345
Protocol 2
User lexluther
PreferredAuthentications publickey,keyboard-interactive,password
Hello Darkphader,
ReplyDeleteOh dear - every second comment that I post is disappearing into the ether. Here's my original comment, as posted at 1:10 AM. A lot of this is wrong.
---
Hi, and thanks for the tips. To specify more than one 'Match' condition in sshd_config, have one Match line following another. E.g.
Match User "bob"
Match 192.168.0.1/24
^ [ WRONG!! ]
The sshd_config(5) manpage says that the tests stop at another Match line, so maybe I made a mistake here; I found that the conditions are ANDed and last until a 'Match' keyword on its own (or EOF). I have public-key authentication on my system and have disabled passwords to stop crackers, but I wanted to enable them for a secret 'emergency' account. I set it up to enable password authentication only for this account, and then set sudo to allow just the 'shutdown' or 'reboot' commands to be run (sudo's manpage is full of confusing BNF, but fortunately, it has lots of examples).
I also have my sshd output a banner to connecting hosts, displaying a confusing mishmash of legal jargon. I've gradually added to this file over the days, and it now outputs half a screen of blurb before login. I admit, the usefulness of this feature is limited, since it serves more to annoy me than anything else. ;)
---
As stated, this is all wrong and I realised that it wasn't working when I tried to log into the 'secret account' from a host that should not have been allowed to login. Testing my OpenSSH (OpenSSH_5.3p1 Debian-3ubuntu5, OpenSSL 0.9.8k 25 Mar 2009) I found that if multiple Match tests are specified on one line, everything after the first test is disregarded. E.g. if I did this:
Match User foo Address 192.168.0.1
.. then 'User foo' would be matched, but the 'Address 192.168.0.1' test would be ignored. This makes me wonder if there's any way to have multiple tests in a Match line, or if it's just my version of ssh. I have found another blog that appears to show a multiple test, but it doesn't work on mine:
[ http://www.gossamer-threads.com/lists/openssh/bugs/45881 ]
---
# allow admins from the dmz with pubkey and password
Match Group admins Address 1.2.3.0/24
RequiredAuthentications publickey,password
---
On my sshd, this will only match 'Group admins'.
I hope that this helps - and warns of some of the pitfalls.
Lex
==================
ReplyDeleteMatch User chris, Address 192.168.0.9
PasswordAuthentication yes
==================
works fine here with version 5.8 (both Linux and OpenBSD), and although the man page(s) specifies comma separated lists (but space separated does work on my Linux box).
"RequiredAuthentications" is not a valid keyword in my versions and only a subset of available keywords can be used in the Match block.
However, my guess, since you're running Linux, is that you're being bitten by "UsePAM yes", change this to "UsePAM no" and let me know if your results are different.