cyqsimon's questions

This question's purpose is to document my findings and solution after two hours of struggle, in hopes that it will be useful to others in the future.

Situation

I've got a fresh Linux machine set up. When logged in to it locally, ls --color=auto correctly displays directory entries in colours. However, when logged in to it remotely via SSH, ls --color=auto does not seem to work.

Why is it so? How to get coloured ls over SSH as well?

Other symptoms

The output of dircolors mirrors the behaviour of ls --color=auto. When running locally, dircolors sets a contentful LS_COLORS environment variable. However when running over SSH, dircolors sets LS_COLORS='' instead.

In OpenVPN's hardening article, it is recommended that the server daemon drop its privileges after startup on Linux:

OpenVPN has been very carefully designed to allow root privileges to be dropped after initialization, and this feature should always be used on Linux/BSD/Solaris. Without root privileges, a running OpenVPN server daemon provides a far less enticing target to an attacker.

They recommend that the following directives be set:

user nobody
group nobody

which I assume mean that the daemon will be running as nobody after startup is complete.

However, there are several files that OpenVPN accesses at runtime, notably the CRL file:

When the crl-verify option is used in OpenVPN, the CRL file will be re-read any time a new client connects or an existing client renegotiates the SSL/TLS connection (by default once per hour). This means that you can update the CRL file while the OpenVPN server daemon is running, and have the new CRL take effect immediately for newly connecting clients.

So naturally I'm worrying if those two features are incompatible - if the daemon drops privileges after startup, how can it read /etc/openvpn/server/crl.pem (owner root:root, mode 0600; SELinux enforcing) at runtime?

• If the daemon is indeed unable to access the CRL file at runtime, is there a good way to circumvent this problem?
• If the daemon can access the CRL files at runtime, I would like to know how this is possible.

OS is RHEL8.5 x86_64 in case that's relevant.

Whenever I log into my RHEL8 server via SSH, I get these lines printed:

Web console: https://<myserver>:9090/ or https://<myip>:9090/

This system is not registered to Red Hat Insights. See https://cloud.redhat.com/
To register this system, run: insights-client --register

How do I disable those prompts?

Using Putty to SSH into a remote Linux (CentOS 7) server from a Windows 10 machine. I would like to know if it's possible to designate a port from which Putty connects to the server.

The backstory:

The server in question has a public IPv4 address, and hence has had its SSH port changed to alleviate brute force attacks. However, I think by the virtue of me having connected from an insecure WIFI hotspot, some attacker has managed to obtain the correct SSH port - recently I have seen a great influx of brute force login attempts that weren't here before.

cat /var/log/secure shows that the attacker(s) come from multiple IP addresses, but they only seem to be using a handful of source ports. Therefore I would like to set up my firewall to only allow incoming SSH connections from a specific source port, in the hopes of slightly improving my security.