Difference between revisions of "Configuring and securing sshd"
imported>ChrisM (New page: All following configuration takes place in /etc/ssh/sshd_config. Be sure to look for existing statements, since in most cases chances are that the configuration option already exists in yo...) |
imported>ThorstenStaerk (link to parent topic) |
||
(8 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
All following configuration takes place in /etc/ssh/sshd_config. Be sure to look for existing statements, since in most cases chances are that the configuration option already exists in your default sshd_config. | All following configuration takes place in /etc/ssh/sshd_config. Be sure to look for existing statements, since in most cases chances are that the configuration option already exists in your default sshd_config. | ||
+ | |||
+ | = Disable Root Login = | ||
+ | |||
+ | You might want to disable root login with: | ||
+ | <pre>PermitRootLogin no</pre> | ||
+ | |||
+ | But in some settings, you still need direct root login without sudo for some purpose (often for remote [[scripting]]). In these situation, permitting root login only for [[public key authentication]] might be a solution: | ||
+ | <pre>PermitRootLogin without-password</pre> | ||
= Disable X11Forwarding = | = Disable X11Forwarding = | ||
− | If you do not want to use X11 forwarding, you should disable it altogether by setting <pre>X11Forwarding No</pre> | + | If you do not want to use X11 forwarding, you should disable it altogether by setting |
+ | <pre>X11Forwarding No</pre> | ||
+ | While X11 is not a real danger for your server, it may cause users to unwillingly reveal private data because a remote client can spoof on the local X server, e.g. capturing passwords as they are typed. | ||
+ | |||
+ | = Restrict the set of allowed users = | ||
+ | |||
+ | The '''AllowUsers''' directory is very useful in limiting SSH access to some of your users. For example, you might have some users, which should be allowed to login on a physical terminal (so they cannot be assigned /bin/false or nologin as a shell), but should not be able to login via SSH. | ||
+ | |||
+ | If you got just one or two active users, use of this setting is also recommended, because one never knows what might create a new user that has a weak password (probably a bogus package's post-install script?). | ||
+ | |||
+ | <pre>AllowUsers user1 user2</pre> | ||
+ | |||
+ | = AllowGroups / DenyUsers = | ||
+ | |||
+ | '''AllowGroups''' and '''DenyUsers''' work just as '''AllowUsers'''. | ||
+ | |||
+ | = Disable password authentification = | ||
+ | |||
+ | If you know that all of your users will login via public key, you can disable password authentification altogether: | ||
+ | <pre>PasswordAuthentification no</pre> | ||
+ | |||
+ | Setting only this single setting will defy 99,9% of all brute force bots out there that are attacking your server constantly, but the downside is (of course) that you cannot login to your server from a machine that is not in ~/.ssh/authorized_keys. | ||
= Putting sshd on a non-standard port = | = Putting sshd on a non-standard port = | ||
Line 12: | Line 41: | ||
'''Note: If you still want the default of 22, you must specify it explicitly now, since you have a differing port already configured.''' | '''Note: If you still want the default of 22, you must specify it explicitly now, since you have a differing port already configured.''' | ||
+ | |||
+ | = Block hosts with /etc/hosts.deny = | ||
+ | |||
+ | Hosts known to be malicious can be added to the /etc/hosts.deny file. You can also use a script like denyhosts that maintaines this file automatically based on sshd log file analysis. | ||
+ | |||
+ | = Changing the MOTD (Message Of The Day) = | ||
+ | |||
+ | To change the MOTD, edit /etc/motd and /etc/issue. In theory issue is printed before the login, while the MOTD is printed after a successful login, but this applies more or less loosely in most modern systems. | ||
+ | |||
+ | = See also = | ||
+ | * [[security]] |
Latest revision as of 14:23, 21 January 2012
All following configuration takes place in /etc/ssh/sshd_config. Be sure to look for existing statements, since in most cases chances are that the configuration option already exists in your default sshd_config.
Contents
Disable Root Login
You might want to disable root login with:
PermitRootLogin no
But in some settings, you still need direct root login without sudo for some purpose (often for remote scripting). In these situation, permitting root login only for public key authentication might be a solution:
PermitRootLogin without-password
Disable X11Forwarding
If you do not want to use X11 forwarding, you should disable it altogether by setting
X11Forwarding No
While X11 is not a real danger for your server, it may cause users to unwillingly reveal private data because a remote client can spoof on the local X server, e.g. capturing passwords as they are typed.
Restrict the set of allowed users
The AllowUsers directory is very useful in limiting SSH access to some of your users. For example, you might have some users, which should be allowed to login on a physical terminal (so they cannot be assigned /bin/false or nologin as a shell), but should not be able to login via SSH.
If you got just one or two active users, use of this setting is also recommended, because one never knows what might create a new user that has a weak password (probably a bogus package's post-install script?).
AllowUsers user1 user2
AllowGroups / DenyUsers
AllowGroups and DenyUsers work just as AllowUsers.
Disable password authentification
If you know that all of your users will login via public key, you can disable password authentification altogether:
PasswordAuthentification no
Setting only this single setting will defy 99,9% of all brute force bots out there that are attacking your server constantly, but the downside is (of course) that you cannot login to your server from a machine that is not in ~/.ssh/authorized_keys.
Putting sshd on a non-standard port
This is security by obfuscation only and is of little value if someone uses port scanner to check, whether a ssh daemon is running on a non-standard port. Anyway, it can be useful if you need to access your server from somewhere, where TCP port 22 outgoing is blocked. Just extend your sshd_config:
Port port ListenAddress 0.0.0.0:port
Note: If you still want the default of 22, you must specify it explicitly now, since you have a differing port already configured.
Block hosts with /etc/hosts.deny
Hosts known to be malicious can be added to the /etc/hosts.deny file. You can also use a script like denyhosts that maintaines this file automatically based on sshd log file analysis.
Changing the MOTD (Message Of The Day)
To change the MOTD, edit /etc/motd and /etc/issue. In theory issue is printed before the login, while the MOTD is printed after a successful login, but this applies more or less loosely in most modern systems.