This post will describe two different methods for securing SSH that work on both Tiger and Leopard (client or server). These tips can be done as needed on machines that will have ssh enabled, or as part of your deployment image(s). Personally, I make these changes to our images because if a machine is bound to a directory service such as Open Directory, Active Directory or LDAP and the user is an admin of their own machine, then all users within your domain can remotely log in to that machine. This would greatly increase your chances of your machines being compromised from an ssh dictionary attack. Also, I find that some of our users will enable services such as SSH and never use them, and I know this because they never came to us when they found they weren’t able to ssh into their own machine. In which case I will send out a command to disable ssh on those machines periodically without them even noticing (because they’re not using it!).
The methods I will describe here are:
- Modify the /etc/sshd_config file
- Service access control lists (SACL)
Modify the sshd_config file
The /etc/sshd_config file is the main configuration file for the sshd daemon program. Before you make any changes to this (or any other) config file, make a backup copy of it.
cp /etc/sshd_config /etc/sshd_config.backup
The main change I make to this file is to add the AllowUsers directive. AllowUsers is not there by default but can be added anywhere in the file. I add it under the #Authentication section. The syntax is simply:
AllowUsers sshuser1 sshuser2
In my images, I have our local admin account listed there but that is optional. If you simply have AllowUsers in that file, it will prevent anyone from authenticating to that machine (even root). Your users will need to come to you for access.
Other changes I make to this file are to change these 2 lines:
#PermitRootLogin yes #Protocol 2,1
PermitRootLogin no Protocol 2
SSH protocol 1 is outdated, probably never used and is ridden with security holes that will never be fixed. I believe Leopard now defaults to protocol 2 only now. I like to limit root on workstations as much as possible and prevent root from logging in remotely should almost never be needed with a password. If you really need to do ssh logins with root and you’re [hopefully] using ssh keys, you can change that line to PermitRootLogin without-password which will require that root use an ssh key. This works out well for remote backups using rsync over ssh (such as what Carbon Copy Cloner uses).
Keep in mind that modifying the sshd_config file can be modified back to default by your users if they are given admin rights and/or sudo.
See man sshd_config for more information.
Service Access Control Lists (SACL)
Using SSH SACL will give your managed computers a 2nd method of ssh security. This will be another barrier your users will have to overcome if they want to enable and use SSH without coming to you first. SSH access can be limited to members of the com.apple.access_ssh group.
First, check if the group exists already (it will if you used the Sharing pane of System Preferences to limit access):
If notthing is returned, it’s not there yet. If it doesn’t exist, create it with:
dseditgroup -o create -q com.apple.access_ssh
Then (optionally) add user(s) to that group (replace sshduser1 with the shortname of the user you are granting ssh access to):
dseditgroup -o edit -a sshuser1 -t user com.apple.access_ssh
See man dseditgroup and man dscl for more information.
Leopard (unfortunately IMHO) added the ability to modify this group in the Sharing pane of System Preferences which gives your [admin] users the ability to easily grant themselves ssh access. This is why you may want to use both methods to secure sshd.