Network on TokkNet

Determine route for IP

blog@tokknet.eu (Tokk) — Thu, 10 Apr 2025 10:59:49 +0200

To determine the route for a specific IP on a system with several gateways, ip route show to match can be used:

user@system:~$ ip route show to match 10.190.10.6
default via 192.168.2.1 dev ens160 proto static
10.0.0.0/8 via 192.168.2.250 dev ens160 proto static src 192.168.2.10

Deactivate password login via SSH under Ubuntu

blog@tokknet.eu (Tokk) — Fri, 28 Jun 2024 09:40:27 +0200

One of the first things I always change on a new server is the sshd_config, deactivating the login via SSH with password.

PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
KbdInteractiveAuthentication no
UsePAM no

Normally you assume that the entries are correct and working, test the login from your own PC and are satisfied that the certificate is being used.

Cloud Init

Of course, Ubuntu is nowadays delivered with Cloud Init and since Ubuntu 20.04 this comes with a new config file called /etc/ssh/sshd_config.d/50-cloud-init.conf, which contains one single line:

PasswordAuthentication yes

Since the inclusion of the sshd_config.d directory takes place very high up in the sshd_config, this is almost always the first occurrence of the PasswordAuthentication directive and is therefore retained and the password login remains activated despite all other settings.
To completely deactivate the option of logging in with a password, the file must therefore be deleted or edited. However, as this file only fulfills one purpose, it can be deleted with a clear conscience.

Concluding remarks

This situation clearly shows that security settings must always be tested, no matter how carefully the configuration is carried out, even from the perspective of an external context, in this case forcing the login without your own certificate.
WTF Canonical?

Unprivileged Binding to Privileged Ports

blog@tokknet.eu (Tokk) — Thu, 27 Jun 2024 09:43:27 +0200

Normally, the Linux kernel does not allow unprivileged processes to bind to ports below 1024. Therefore, most (web) server processes run as root. From a security point of view, it is of course not ideal for the processes that handle requests from the Internet to have extensive rights, as this naturally leads directly to root rights on the entire system in the event of a hostile takeover of the process.
At this point, however, Systemd offers the possibility of allowing our service to bind to the ports by granting the corresponding process the authorization to bind to the ports below 1024 via AmbientCapabilities =CAP_NET_BIND_SERVICE. An overview of all other authorizations that can be granted can be found, for example, in the Linux man page on capabilities.

On this occasion, you can use CapabilityBoundingSet=CAP_NET_BIND_SERVICE to restrict that the service may only receive this authorization and cannot receive any other authorizations. The unit file should then look like this:

[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE

It is best to create such changes as a drop-in in a separate override file.

Translated with DeepL.com (free version)