completes the sshd doc
This commit is contained in:
parent
211cedccb6
commit
c025fd0e46
|
|
@ -403,30 +403,183 @@ This might look a bit intimidating but I'll break down the command line options
|
|||
* `--ssh-cmd -i student` is needed to specify our specific private key (not needed if you use `~/.ssh/id_rsa.pub`)
|
||||
* `-D` will daemonize the VPN so you can continue to use the shell
|
||||
|
||||
A more basic way of creating a VPN over ssh, if you use your main `~/.ssh/id_rsa` file is identity, would be as follows.
|
||||
You can't execute this command because your public key is not present on this server but it's to give you a more bare bones idea of a valid sshuttle.
|
||||
Note that here I connect not to the standard port 22 but to a custom port 4040.
|
||||
This command won't daemonize so you would need to open a second terminal to execute other commands.
|
||||
|
||||
```
|
||||
➜ ~ git:(master) ✗ sshuttle -r pi@home.86thumbs.net:4040 -x home.86thumbs.net 0.0.0.0/0
|
||||
```
|
||||
|
||||
**Can you explain me why you need you're prompted for your `sudo` password?**
|
||||
|
||||
## Tweaking the sshd configuration file
|
||||
|
||||
All server configuration is done in the `/etc/ssh/sshd_config` file.
|
||||
Starting version TO_CHECK you can use the modern `/etc/ssh/sshd_config.d/` folder system to override default system configuration.
|
||||
This way any changes to the standard configuration made by the package maintainers won't mess with your custom preferences and tweaks.
|
||||
I highly recommend to read through the `man sshd_config` pages for a detailed explanation of all possible settings.
|
||||
The Debian configuration is quite secure but we can improve it a bit.
|
||||
Below are some standard security improvements you'll find on lot's of servers.
|
||||
|
||||
### Version
|
||||
**A word of caution.**
|
||||
You can lock yourself out of your server!
|
||||
Try out some options now on your virtual machines so you get a firm understanding of what they all do.
|
||||
If you lock yourself out of a remote server you'll have to either gain physical access or reboot the VPS in rescue mode.
|
||||
For OVH, the VPS provider I tend to use, the rescue mode is detailed [here](https://support.us.ovhcloud.com/hc/en-us/articles/360010553920-How-to-Recover-Your-VPS-in-Rescue-Mode).
|
||||
With other providers it will be different but similar.
|
||||
|
||||
### Some classic security enhancements
|
||||
|
||||
There are more options available but these are some of the most used one.
|
||||
|
||||
#### Version
|
||||
|
||||
A modern sshd configuration will only allow version 2 but you can check or specify this in the configuration file.
|
||||
You'll probably never have to set this yourself but do keep it in mind when you're confronted with old installations.
|
||||
|
||||
```
|
||||
Protocol
|
||||
Specifies the protocol versions sshd(8) supports. The possible values are ‘1’ and
|
||||
‘2’. Multiple versions must be comma-separated. The default is ‘2’. Protocol 1
|
||||
suffers from a number of cryptographic weaknesses and should not be used. It is
|
||||
only offered to support legacy devices.
|
||||
Specifies the protocol versions sshd(8) supports. The possible values are ‘1’ and
|
||||
‘2’. Multiple versions must be comma-separated. The default is ‘2’. Protocol 1
|
||||
suffers from a number of cryptographic weaknesses and should not be used. It is
|
||||
only offered to support legacy devices.
|
||||
|
||||
Note that the order of the protocol list does not indicate preference, because the
|
||||
client selects among multiple protocol versions offered by the server. Specifying
|
||||
“2,1” is identical to “1,2”.
|
||||
Note that the order of the protocol list does not indicate preference, because the
|
||||
client selects among multiple protocol versions offered by the server. Specifying
|
||||
“2,1” is identical to “1,2”.
|
||||
```
|
||||
|
||||
### Some classic security enhancements
|
||||
#### Root login
|
||||
|
||||
Most systems we install, and the ones you'll deploy later, perform system management via `sudo` so there is no point in even allowing the `root` user to log in.
|
||||
We can deny any attempt to log in as root with the following option.
|
||||
I would advise to always set this option to no.
|
||||
|
||||
```
|
||||
PermitRootLogin
|
||||
Specifies whether root can log in using ssh(1). The argument must be yes, prohibit-password,
|
||||
forced-commands-only, or no. The default is prohibit-password.
|
||||
|
||||
If this option is set to prohibit-password (or its deprecated alias, without-password), password and key‐
|
||||
board-interactive authentication are disabled for root.
|
||||
|
||||
If this option is set to forced-commands-only, root login with public key authentication will be allowed,
|
||||
but only if the command option has been specified (which may be useful for taking remote backups even if
|
||||
root login is normally not allowed). All other authentication methods are disabled for root.
|
||||
|
||||
If this option is set to no, root is not allowed to log in.
|
||||
```
|
||||
|
||||
#### Key only login
|
||||
|
||||
Once you properly understand how to do key based login it's wise to disable password login all together for internet facing servers.
|
||||
This protects you for [bruteforce](https://en.wikipedia.org/wiki/Brute-force_attack) attacks and script kiddies.
|
||||
On a LAN you can get away with leaving them but I would still advise to keep it key only as we'll later see how an attacker can forward your ssh server to an off-site remote server.
|
||||
Here I would put no to override the default.
|
||||
|
||||
```
|
||||
PasswordAuthentication
|
||||
Specifies whether password authentication is allowed. The default is yes.
|
||||
|
||||
```
|
||||
|
||||
#### Allow only specific users and groups
|
||||
|
||||
On systems with lot's of users and groups it might be wise to only permit certain groups and/or users.
|
||||
Messing with this setting is a common way of locking oneself out of a server so think before you restart sshd.
|
||||
It's worth noting that upon a restart of your sshd service, your active connection is **not** interrupted so keep it upen en try a login in a different terminal.
|
||||
If you would happen to have locked yourself out you can still use the previous connection to rectify the problem.
|
||||
For VPS servers I often create a group `ssh_allowed` and add myself and other administrators to this group.
|
||||
Then I set the `AllowGroups ssh_allowed` to block all users not in that group from connecting to the server.
|
||||
I often use the `AllowUsers` setting together with `Match` blocks to allow TCP forwarding for one special user but more on that later.
|
||||
|
||||
```
|
||||
AllowGroups
|
||||
This keyword can be followed by a list of group name patterns, separated by spaces. If specified, login
|
||||
is allowed only for users whose primary group or supplementary group list matches one of the patterns.
|
||||
Only group names are valid; a numerical group ID is not recognized. By default, login is allowed for all
|
||||
groups. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers,
|
||||
DenyGroups, and finally AllowGroups.
|
||||
|
||||
See PATTERNS in ssh_config(5) for more information on patterns.
|
||||
|
||||
AllowUsers
|
||||
This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login
|
||||
is allowed only for user names that match one of the patterns. Only user names are valid; a numerical
|
||||
user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form
|
||||
USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particu‐
|
||||
lar hosts. HOST criteria may additionally contain addresses to match in CIDR address/masklen format.
|
||||
The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and
|
||||
finally AllowGroups.
|
||||
|
||||
See PATTERNS in ssh_config(5) for more information on patterns.
|
||||
```
|
||||
|
||||
#### Forwarding
|
||||
|
||||
Unless you need, and we'll need it later, port forwarding it's best to set the `DisableForwarding` option to yes.
|
||||
It is be a bit of an extreme measure but fully understandable.
|
||||
Why enable it if you don't need it?
|
||||
|
||||
```
|
||||
DisableForwarding
|
||||
Disables all forwarding features, including X11, ssh-agent(1), TCP and StreamLocal. This option over‐
|
||||
rides all other forwarding-related options and may simplify restricted configurations.
|
||||
```
|
||||
|
||||
#### Multiple network interfaces
|
||||
|
||||
If you have multiple network interfaces such as an ethernet and a wireless interface you can restrict the server to only listen on one of them.
|
||||
I rarely use this option but it's good to know it exists.
|
||||
Do note that similar behavior can be achieved with `iptables`.
|
||||
|
||||
```
|
||||
ListenAddress
|
||||
Specifies the local addresses sshd(8) should listen on. The following forms may be used:
|
||||
|
||||
ListenAddress hostname|address [rdomain domain]
|
||||
ListenAddress hostname:port [rdomain domain]
|
||||
ListenAddress IPv4_address:port [rdomain domain]
|
||||
ListenAddress [hostname|address]:port [rdomain domain]
|
||||
|
||||
The optional rdomain qualifier requests sshd(8) listen in an explicit routing domain. If port is not
|
||||
specified, sshd will listen on the address and all Port options specified. The default is to listen on
|
||||
all local addresses on the current default routing domain. Multiple ListenAddress options are permitted.
|
||||
For more information on routing domains, see rdomain(4).
|
||||
```
|
||||
|
||||
#### Maximum of authentication tries
|
||||
|
||||
You can limit the amount of tries a user has before the connection is canceled by the server but **watch out with this one**.
|
||||
It acts differently from how you think it does!
|
||||
When a user presents himself to the server, every key in their `~/.ssh/` is presented one by one to the server and each key is a try.
|
||||
So if you set this value too low you might lock yourself out in the future without realizing why.
|
||||
Imagine you only have one key, then everything is fine with a low value but if later down the line you create more keys this could become a problem and I guarantee you it will take you a while to figure it out.
|
||||
|
||||
```
|
||||
MaxAuthTries
|
||||
Specifies the maximum number of authentication attempts permitted per connection. Once the number of
|
||||
failures reaches half this value, additional failures are logged. The default is 6.
|
||||
```
|
||||
|
||||
Have a look at [this](https://unix.stackexchange.com/questions/418582/in-sshd-config-maxauthtries-limits-the-number-of-auth-failures-per-connection) for a more detailed explanation of **what** counts as a **try**.
|
||||
|
||||
### Some *fun* stuff
|
||||
|
||||
You can set banner and motd (message of the day) files that will be shown to the user upon login.
|
||||
This is what bandit uses to draw their ASCII banner when you log in.
|
||||
|
||||
```
|
||||
Banner
|
||||
The contents of the specified file are sent to the remote user before authentication is allowed. If the
|
||||
argument is none then no banner is displayed. By default, no banner is displayed.
|
||||
|
||||
PrintMotd
|
||||
Specifies whether sshd(8) should print /etc/motd when a user logs in interactively. (On some systems it
|
||||
is also printed by the shell, /etc/profile, or equivalent.) The default is yes.
|
||||
```
|
||||
|
||||
### Tunneling and X forward
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue