Written for OpenSSH_6.6.1p1 Ubuntu based (Actually LM)
Other versions might have more or less features. Test and see what works.
Also, when I say LAN network, I presume it starts with 192.168.1. Different routers will assign different local ips.
I'm writing this to help increase general security while using ssh while also permitting plenty of usability.
Prior, when I was trying to figure this all out, a lot of the ssh documentation was extremely confusing and often outdated.
So if you have had a similar experience trying to setup sshd, hopefully this will be of use.
I expect you have a working openssh server setup and understand the basic options and know
how to test new configs without locking yourself out (hint: don't close the original connection)
If you have a
ssh server facing the Internet, please read through this.
There should be
no reason for decreased security, even when using passwords via external ips!
However, using public key auth will always be significantly more secure and should be considered best practice to use.
Some things I will cover
- Explanation and examples of AllowUsers, AllowGroups, DenyUsers, DenyGroups
- Explanation and examples of Matching statements
- Using combinations of Allow/Deny and Match statements to support complex situations
- Connecting via password from external address
The OpenSSH Server configuration file is located at /etc/ssh/sshd_config
The options inside are obeyed from top to bottom.
So if you put in
PasswordAuthentication no
PasswordAuthentication yes
Then passwords are allowed. Thus,
all default configurations must be above the conditional options in the file.
Best Practice:
In general, make sure to make permissions as limited as possible. This is much better then opening the gates and putting up numerous barriers
to stop intruders.
Say no to everyone, then say yes to a very select choice of users.
If you must have password access, ensure the users using password access have exceptionally limited permissions.
No matter how small the door is, if your one user permitted passwords has a easy password and root (or sudo) access, you are asking for trouble.
____________________________________
AllowUsers, AllowGroups, DenyUsers, DenyGroups
The names should explain themselves.
e.g. if you set a AllowUsers option, that user will be permitted while everyone else is denied.
If you set DenyGroups, that group will be denied but all others will be permitted.
If a person matches multiple (in allow users but in deny groups) behavior has been a little inconsistent.
Deny seems to be more powerful then Allow. I suggest testing to see how it acts on your system.
My sshd_config man page says it is processed in this order:
DenyUsers, AllowUsers, DenyGroups, then AllowGroups.
If you specify multiple AllowUsers (or any other) it will compound them.
Here's some examples of setups.
If I want everyone in group admin but user hazcheezburger to have access while everyone else is denied
Code:
AllowGroups admin
DenyUsers hazcheezburger
Multiple options are permitted.
Users alice and bob are permitted, everyone else is denied.
Code:
AllowUsers alice bob
Wildcards are permitted as well. * means any or all. ? Meaning anything for that character
! negates the option.
This will deny all groups starting with user_ and permit user alice but not bob from accessing
Code:
AllowUsers ?????
DenyGroups user_*
You do not want user bob connecting but wish to permit alice and charlie (yes, denyuser would the better method of doing this)
Code:
AllowUsers !bob alice charlie
SSH deals with network connections. Oftentimes, people will connect from one ip address. If they connect from another one, that could indicate a risk.
Let's ensure the user backup_files (a automated user that connects from 72.45.21.664) can only login from one address.
However, we want to ensure user sam can login from any lan address
Code:
AllowUsers backup_files@72.45.21.664 sam@192.168.1.*
Now let's make sure sam can login from lan and his work ip, 23.432.36.1. However, the local ip 192.168.1.20 is known to be extremely insecure, so we won't let sam login from there
Code:
AllowUsers sam@192.168.1.*,23.432.36.1,!192.168.1.20
Let's make a bad example. I'm trying to block user hacker in group evil who uses a lan connection but want to permit everyone else to access via lan.
Code:
AllowUsers *@192.168.1.* !hacker
This will permit hacker to login. Do you know why? I'll post the answer later.
____________________
Matching statements
Sometimes we want fine-grained control of what goes on. While the Allow/Deny options are useful, they are sweeping in that the two possible options are to deny or permit access.
This is where using Match comes into play. Remember to ensure these are placed at the bottom of the file, to prevent overruling.
Also, not all config options can be changed. Look through man sshd_config for full list & make sure to test your sshd config
There are a few possible options. There are more, but I see these to be the most useful.
Address refers to a ip address (e.g. 192.168.1.25) and hosts refer to dns lookup.
Someone from linuxquestions.org logging in? Use Host to modify their login.
To write a generic match statement, it goes like this
Code:
Match Filter Argument
Option Argument
The best example of using addresses to match is to ensure external connections cannot use passwords, but
local connections can use passwords
This will set a default of no password auth, but anyone connecting from 192.168.1.* is permitted
Code:
PasswordAuthentication no
Match Address 192.168.1.*
PasswordAuthentication yes
alice & bob are permitted to use X11 forwarding, however the default is set to deny.
Code:
X11Forwarding no
Match User alice,bob
X11Forwarding yes
Groups work in a similar way and can be combined with other options.
Let's permit groups admin or homework or user alice to use x11 forwarding
Code:
X11Forwarding no
Match Group admin,homework User alice
X11Forwarding yes
These options can be combined for specialized purposes.
Generally, the security risks of X11 forwarding are reduced in the lan network. But the only users who need it belong in group gui.
I will also give everyone in the lan network permission to use password authentication
Notice if I combined the below Matching statements, it would only permit those in lan
and group gui to use pass auth. Everyone else would not be permitted.
Code:
PasswordAuthentication no
X11Forwarding no
Match Group gui Address 192.168.1.*
X11Forwarding yes
Match Address 192.168.1.*
PasswordAuthentication yes
Here we mandate that banners will be displayed to all users except those in the group nobanner.
Code:
Banner none
Match User * Group !nobanner
Banner /etc/banner
________
3 Complex examples
1.
Let's say you are setting up the ssh server for the main connection between external and internal connections for a school. Administrators in the group admin are permitted to login from anywhere
but must not use x11 forwarding or passwords if from a external network. Students in the group student must be within the lan to connect, are permitted to use password auth but
not permitted to use x11 forwarding. There is a IT support tech that manages schools up and down the district who must have x11 forwarding access from her home address (32.65.435.63) lan and work ip which may vary but
will start with 92.45.13., her username is sally and is part of the admin group.
Everyone else should be denied
Code:
X11Forwarding no
PasswordAuthentication no
AllowGroups admin student@192.168.1.*
Match Address 192.168.1.* Group admin
PasswordAuthentication yes
X11Forwarding yes
Match Group student
PasswordAuthentication yes
Match User sally Address 192.168.1.*,32.65.435.63,92.45.13.*
X11Forwarding yes
2.
A individual uses his home computer to write documents for his business. He wants to be able to access this from his work with a ip address of 24.562.2.526 but sometimes will connect
from the local cafe which has the ip of 75.743.1.632. He trusts the security of his work network so password auth is ok but does not trust the cafe, which should be key based.
He will be the only user ever connecting to this computer and the server should never permit any other user from accessing, nor should anyone be able to access the server from
any other ip address. His username is uplink
Code:
PasswordAuthentication no
AllowUser uplink@24.562.2.526,75.743.1.632
Match Address 24.562.2.526
PasswordAuthentication yes
3.
A group of people use ssh in their building to login to each other's computer for work. One of them will be going to another country for a few months to work on a project.
Let's ensure he can continue to do his job, however we must make sure no one else can access via external network. He will be using key based auth but passwords are acceptable in lan.
He doesn't know what ip he'll be connecting from but plans to followup with the info. his username is rocker
Code:
PasswordAuthentication no
AllowUser *@192.168.1.* rocker
Match Address 192.168.1.*
PasswordAuthentication yes
Later on, you notice in the logs rocker is connecting from 999.23.53.1. He confirms he will be consistently connecting from this ip. He is using key based auth, which is secure,
however you decide to update the config to be safe. If someone manages to get his private key, it will be useless unless from the one ip address.
Code:
AllowUser *@192.168.1.* rocker@999.23.53.1
_____
Password based Authentication open to external networks.
Pretty much every guide out there says do not permit passwords to external ips. I agree.
But people need it sometimes. Before you set it though, think for a moment and answer these questions:
- Do you need ALL users to be able to login with password from anywhere? Maybe just one user?
- Would it be ok to permit passwords in the lan, but restrict users using passwords from external ip's?
- Will users be using the same network to connect from? Would it be ok to restrict passwords to limited ip's?
Also, if you have to use passwords for external ips...
Make sure to use a strong password and additional protections such as banning programs when too many invalid attempts are made
Even a
5 minute ban on a ip after 3 guesses can be
the difference between being cracked and making the attack too expensive to pursue.
There are a assortment of
easy to use and effective programs out there. I use
fail2ban. A 5 minute ban will not ruin your day. A hacked computer will.
If you have a username of miati (don't use something easy, like admin)
Code:
PasswordAuthentication no
Match User miati
PasswordAuthentication yes
or to only permit one user to login
Code:
PasswordAuthentication no
AllowUser miati
Match User miati
PasswordAuthentication yes