cf7/ittavern.com
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases Packages Wiki Activity Actions

DEL HTML anchors from posts as they are going to be added automaticly with new ssg

Browse source
This commit is contained in:
Caffeine Fueled 2025-10-27 20:20:04 +01:00
parent 3484b45045
commit 3d28d5eee9
Signed by: cf7
GPG key ID: CA295D643074C68C
26 changed files with 263 additions and 263 deletions
Download patch file Download diff file Expand all files Collapse all files

42
items/2023-11-22_long_ssh-server-hardening.md
View file

@ -14,7 +14,7 @@ I'll use Linux with an SSH server as a reference (`OpenBSD Secure Shell server`
Additionally, DO NOT copy any configuration mindlessly! - Some configuration changes are just recommendations and work in most cases, but make sure those work for your system, too.
# SSH Server Configuration <a href="#config-file" id="config-file">#</a>
# SSH Server Configuration
The following configurations can be changed in the `/etc/ssh/sshd_config` file or in a separate configuration file that can be created in a subdirectory `/etc/ssh/sshd_config.d/*.conf`.
@ -32,7 +32,7 @@ Use `sudo sshd -T` for a more **verbose output**, which additionally displays al
Almost every config file change **requires a restart of the SSH server service**.
## Public key authentication <a href="#public-key-auth" id="public-key-auth">#</a>
## Public key authentication
You can find a guide on how to use public key authentication [in this linked article](https://ittavern.com/ssh-how-to-use-public-key-authentication-on-linux/). I highly recommend securing your server with public key authentication instead of password authentication.
@ -43,7 +43,7 @@ After enabling it, make sure to turn off password authentification:
It requires some configuration on the server and client, but it is worth it as it is one of the best ways to protect your server.
## Changing the ssh port <a href="#changing-ssh-port" id="changing-ssh-port">#</a>
## Changing the ssh port
`Port 2222`
@ -63,7 +63,7 @@ Change the default SSH port `22` of your host to something else. Some people thi
**Side note:** choosing a port below 1024 (system or well-known port) is recommended to make it more difficult for an unprivileged user to highjack the service, as by default, non-root processes can only open ports above 1023. Just make sure to avoid **conflicts with already used ports**.
## Disable root login <a href="#disable-root-login" id="disable-root-login">#</a>
## Disable root login
`PermitRootLogin no`
@ -71,13 +71,13 @@ Prohibits connecting as `root` as it is recommended to work with a separate user
I've got some feedback that it is unnecessary to disable this since users with `sudo` permissions could do the same damage, but I disagree. Most - if not all - systems have a `root` user, and this is known, which makes it easy to run brute-force or dictionary attacks against the system. Most attackers don't know the available users on a system, which makes the `username` a kind of password.
## Disable login attempts with empty passwords <a href="#disable-empty-passwords" id="disable-empty-passwords">#</a>
## Disable login attempts with empty passwords
`PermitEmptyPasswords no`
It is fairly self-explanatory, but to make sure, allowing any account without a password to log into the system is a big no-no and should be turned off immediately.
## Disable SSHv1 and use SSHv2 <a href="#disable-sshv1" id="disable-sshv1">#</a>
## Disable SSHv1 and use SSHv2
`Protocol 2`
@ -109,7 +109,7 @@ SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.3
**Important:** If you see `SSH-1.99` as version, it means that SSHv1 is enabled and it should be disabled!
## Restrict access to specific users or/and groups <a href="#restrict-users-access" id="restrict-users-access">#</a>
## Restrict access to specific users or/and groups
`AllowUsers a_this a_that`
@ -117,7 +117,7 @@ SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.3
This option is pretty straightforward and limits the users or groups that can access the server via SSH.
## Restrict access to specific IP or network <a href="#restrict-network-access" id="restrict-network-access">#</a>
## Restrict access to specific IP or network
`AllowUsers *@10.10.10.10` *# affects all users*
@ -127,13 +127,13 @@ This option is pretty straightforward and limits the users or groups that can ac
You can further limit the access to specific IPs or networks.
## Restrict access to specific interfaces <a href="#specific-interface" id="specific-interface">#</a>
## Restrict access to specific interfaces
`ListenAddress 10.10.10.10`
Most servers have multiple interfaces. If the server has one interface for the internal network and one for the internet, and you don't need to reach the server over the internet, it is recommended to make the SSH server listen only to the internal IP. The default is `0.0.0.0`, which allows the service to listen to all interfaces.
## Set an authentication timer <a href="#authentication-timer" id="authentication-timer">#</a>
## Set an authentication timer
`LoginGraceTime 20`
@ -141,7 +141,7 @@ The authentication must happen in 20 seconds before the connection gets closed.
**Side note:** make sure that this limit works for you. This limit won't be a problem for Public Key Authentication, but if you have to wait for mail to arrive with the MFA token, 20 seconds might be too short.
## Limit maximum number of attempted authentications <a href="#limit-authentication-attempts" id="limit-authentication-attempts">#</a>
## Limit maximum number of attempted authentications
`MaxAuthTries 3`
@ -149,7 +149,7 @@ The default is `6`, and lowering it makes it a little bit more difficult to brut
**Side note:** Every SSH key loaded into the ssh-agent counts as one attempt each. Keep this in mind if you have a bunch of keys loaded! Additionally, if the Kerberos/GSSAPI authentication method is enabled, the look-up of whether the client is authenticated counts as one attempt.
## Limit the number of concurrent unauthenticated connections <a href="#limit-unauthenticated-conn" id="limit-unauthenticated-conn">#</a>
## Limit the number of concurrent unauthenticated connections
`MaxStartups 10:30:100`
@ -166,7 +166,7 @@ The randomized connection dropping makes it more difficult to DOS the service wi
This option only affects pre-authentication connection and does not limit anything else. Additionally, it has nothing to do with the following option.
## Restrict Multiplexing <a href="#restrict-multiplexing" id="restrict-multiplexing">#</a>
## Restrict Multiplexing
`MaxSessions 10`
@ -187,7 +187,7 @@ Setting `MaxSessions` to `0` disables all shell, login, and subsystem sessions b
This option can be used to **limit the permissions of a bastion/jump host user or group** to a single task.
## Set up a session timeout <a href="#session-timeout" id="session-timeout">#</a>
## Set up a session timeout
`ClientAliveCountMax 3`
@ -195,7 +195,7 @@ This option can be used to **limit the permissions of a bastion/jump host user o
The configuration above means that the session is terminated after 6 minutes of client inactivity. After `120` seconds without receiving any data from the client, the server will ask if the client is still there. If the client does not respond, the server will try it again in `120` seconds. If the client fails to answer `3` times, the session is getting terminated.
## Hide Linux Version in identification string <a href="#hide-linux-version" id="hide-linux-version">#</a>
## Hide Linux Version in identification string
`DebianBanner no`
@ -214,7 +214,7 @@ Please note that the rest of the identification string must remain unchanged acc
SSH-protoversion-software version SP comments CR LF
```
## Disable tunneling and port forwarding <a href="#disable-tunneling" id="disable-tunneling">#</a>
## Disable tunneling and port forwarding
`AllowAgentForwarding no`
@ -224,7 +224,7 @@ Please note that the rest of the identification string must remain unchanged acc
Disabling those functions makes it more difficult to use the server as a jump host to gain access to the connected networks, malicious or not. Most servers do not need those functions enabled, but to learn more, feel free to check my article about [SSH tunneling and port forwarding](https://ittavern.com/visual-guide-to-ssh-tunneling-and-port-forwarding/).
## Disable unused authentification methods <a href="#disable-unused-auth-methods" id="disable-unused-auth-methods">#</a>
## Disable unused authentification methods
`KerberosAuthentication no`
@ -237,19 +237,19 @@ It highly depends on your needs, but if an authentification method is unused, it
**Side note:** Please ensure you don't disable the only method you can log in to prevent a lockout.
## Disable X11 Forwarding <a href="#disable-x11" id="disable-x11">#</a>
## Disable X11 Forwarding
`X11Forwarding no`
The security concern here is that X11 forwarding opens a channel from the server to the client. In an X11 session, the server can send specific X11 commands to the client, which can be dangerous if the server is compromised. [Source](https://security.stackexchange.com/a/14817)
## Disable SFTP subsystem <a href="#disable-sftp" id="disable-sftp">#</a>
## Disable SFTP subsystem
If you do not need SFTP, disable it. It decreases the attack surfaces and makes the system less vulnerable to security flaws.
Just comment out the `Subsystem sftp [...]` out of the config by placing a `#` at the beginning of the lines.
## Disable insecure ciphers and MACs <a href="#disable-ciphers" id="disable-ciphers">#</a>
## Disable insecure ciphers and MACs
```markdown
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
@ -265,7 +265,7 @@ There are even some more restrictive options, but I have not tested them myself.
Auditing tools like [ssh-audit](https://github.com/jtesta/ssh-audit) can tell you what is secure and what is not.
# Host Server configurations <a href="#host-server-config" id="host-server-config">#</a>
# Host Server configurations
I won't go into detail in this section as it is not in the scope. I just reference methods that I have already covered and name others that can help you secure your server even further.