Solved Ubuntu /var/log/auth.log and others are empty
I have detected a problem on my Ubuntu server.
If the topic does not belong here, please let me know directly and delete it...
I was wondering why fail2ban does not lock anything. And then I noticed that even though there are incorrect logins via ssh, the file /var/log/auth.log remains empty.
I noticed other empty files:
alternatives.log, fontconfig.log, bootstrap.log, cloudron-setup.log.
But I have no idea if this is normal.
The server was installed the day before yesterday by netcup.de. Here the automatic installation with the Ubuntu 18.04 LTS Image with preinstalled Cloudron was used.
I just tried a new installation (after a snapshot). The problem remains.
But maybe this is all normal and I am doing something else wrong?!
Thanks for your help!
@dieter This is normal. Cloudron does not use fail2ban. For SSH login, we recommend to simply use SSH keys - https://cloudron.io/documentation/security/#securing-ssh-access . That way, blocking IPs and monitoring them etc is superfluous.
That said, we are looking into adding some firewall related features in Cloudron in coming release. But it won't be IP based, it will be more like an application firewall which will block/rate limit specific routes (like login route of an app).
Thanks @girish for your answer. But exactly over the page you gave me I came to fail2ban.
I installed and tested it and then found out that it does not work. If you write that it is normal that nothing is recorded in the file, it can not work either.
It's good to read that you are working on a firewall solution and that ssh keys can be used to secure access, but currently the given solution does not work with fail2ban, which can lead to a false sense of security.
To make myself clearer:
I was only going to use fail2ban to block brute force SSH logins, as indicated.
@dieter I found that the SSH logs are in
journalctl -u ssh. It's also important to have the syslog facility *disabled in
# Logging #SyslogFacility AUTH #LogLevel INFO
Just to clarify: cloudron does not setup/manage SSH configs. This seems to be just standard ubuntu configuration.
To add here, SSHd configs are very often VPS provider specific even, not just Ubuntu. So ideally Cloudron should not try to manage too much around that, since then this might interfere with for example SSH recovery strategies from VPS provider.
Generally it is always a good idea to use ssh keys instead of password.
@nebulon Found this thread and wanted to raise this issue again. I noticed the same - /var/log/auth.log is empty after a fresh Cloudron installation on a dedicated Ubuntu 20.04 server. I also followed the docs and enabled fail2ban for handling invalid SSH login attempts. However, fail2ban by default reads login attempts from /var/log/auth.log. Is there some setting during the installation of Cloudron that disables SSHD logging to /var/log/auth.log? If so, why? Thanks.
Also, to clarify, SSHD logs were going to /var/log/auth.log prior to installing Cloudron.
@staypath Sorry. I should have dug into the setup scripts more before asking. I found this entry in /home/yellowtent/box/setup/start.sh, which disables journald logging to syslog. I assume this is what is preventing SSHD logs from being sent to /var/log/auth.log. Is there any danger in re-enabling journald forwarding to syslog?
echo "==> Configuring journald" sed -e "s/^#SystemMaxUse=.*$/SystemMaxUse=100M/" \ -e "s/^#ForwardToSyslog=.*$/ForwardToSyslog=no/" \ -i /etc/systemd/journald.conf
Otherwise, what are recommendations for using fail2ban to protect against SSH login attempts on the server?
@staypath Continuing my conversation with myself
Posting this here in case anyone else comes across this with the same question: I found that configuring fail2ban to use systemd was the trick:
[sshd] port = ssh #logpath = %(sshd_log)s #backend = %(sshd_backend)s backend = systemd enabled = true maxretry = 1 bantime = 14d