Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


    Cloudron Forum

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Solved Ubuntu /var/log/auth.log and others are empty

    Support
    ssh security firewall
    4
    9
    1530
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      dieter last edited by girish

      Hello, everyone,

      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!

      Greetings
      René

      1 Reply Last reply Reply Quote 0
      • girish
        girish Staff last edited by

        @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).

        1 Reply Last reply Reply Quote 0
        • D
          dieter last edited by

          Thanks @girish for your answer. But exactly over the page you gave me I came to fail2ban.
          https://cloudron.io/documentation/security/#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.

          1 Reply Last reply Reply Quote 0
          • D
            dieter last edited by

            To make myself clearer:
            I was only going to use fail2ban to block brute force SSH logins, as indicated.

            1 Reply Last reply Reply Quote 0
            • girish
              girish Staff last edited by

              @dieter I found that the SSH logs are in journalctl -u ssh. It's also important to have the syslog facility *disabled in /etc/ssh/sshd_config:

              # Logging
              #SyslogFacility AUTH
              #LogLevel INFO
              

              Just to clarify: cloudron does not setup/manage SSH configs. This seems to be just standard ubuntu configuration.

              1 Reply Last reply Reply Quote 0
              • nebulon
                nebulon Staff last edited by

                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.

                S 1 Reply Last reply Reply Quote 0
                • S
                  staypath @nebulon last edited by staypath

                  @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.

                  S 1 Reply Last reply Reply Quote 0
                  • S
                    staypath @staypath last edited by

                    @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?

                    S 1 Reply Last reply Reply Quote 0
                    • S
                      staypath @staypath last edited by

                      @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
                      
                      1 Reply Last reply Reply Quote 1
                      • First post
                        Last post
                      Powered by NodeBB