Adjusting the log level on an SSH server enables detailed visibility into connection attempts, authentication failures, and session activity, which is essential for troubleshooting and security auditing.
The OpenSSH daemon reads its configuration from /etc/ssh/sshd_config and writes messages through the system logging facility, commonly to /var/log/auth.log on Ubuntu and /var/log/secure on many RHEL-derived systems, using the LogLevel directive to control how much detail is recorded for each connection.
Increasing the LogLevel to VERBOSE or DEBUG3 can generate a large volume of log data and slightly increase CPU and disk usage, so such settings are best kept temporary for troubleshooting; the examples here target Ubuntu systems using systemd, while other Linux distributions use the same LogLevel directive but may log to different files.
Steps to configure verbose logging for SSH server:
- Open a terminal session on the SSH server with a user account that can run sudo.
$ whoami admin
- Create a backup copy of the current /etc/ssh/sshd_config file.
$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%Y%m%d%H%M%S)
Mis-editing /etc/ssh/sshd_config can prevent new SSH logins, so keeping a backup simplifies rollback if a mistake is made.
- Open the /etc/ssh/sshd_config file in a text editor.
$ sudo vi /etc/ssh/sshd_config
Any preferred text editor such as nano, vim, or vi can be used for editing the configuration file.
- Locate the LogLevel directive in the file, or add it near the other global settings if it is missing.
LogLevel INFO
If a LogLevel line is present but starts with #, removing the hash activates the directive.
- Set the LogLevel to a more verbose value such as VERBOSE or DEBUG3 for detailed troubleshooting.
LogLevel DEBUG3
Valid LogLevel values are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG1, DEBUG2, and DEBUG3, with DEBUG3 being the most verbose.
High verbosity, especially DEBUG3, can quickly grow log files and consume disk space, so it should only be used temporarily.
- Save the changes in the editor and return to the shell prompt.
- Test the sshd configuration for syntax errors before restarting the service.
$ sudo sshd -t
No output from sshd -t indicates that the configuration syntax is valid.
- Restart the ssh service to apply the new log level.
$ sudo systemctl restart ssh
- Check the ssh service status for an active state and recent log messages.
$ sudo systemctl status ssh ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2025-12-11 10:15:01 UTC; 5s ago ##### snipped ##### - Monitor the authentication log to confirm that verbose SSH entries are being recorded.
$ sudo tail -f /var/log/auth.log Dec 11 10:15:03 server sshd[12345]: debug3: authmethod_is_enabled publickey Dec 11 10:15:03 server sshd[12345]: debug1: userauth-request for user alice service ssh-connection method publickey Dec 11 10:15:03 server sshd[12345]: Accepted publickey for alice from 192.0.2.10 port 54832 ssh2: RSA SHA256:##### snipped #####
On some Linux systems, SSH authentication messages appear in /var/log/secure or only in the systemd-journald log, which can be viewed with journalctl -u ssh.
- Return the LogLevel to a normal value such as INFO after troubleshooting to reduce log volume.
LogLevel INFO
Leaving DEBUG3 enabled permanently increases noise in the logs and may hide important events among excessive debug messages.
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.
Comment anonymously. Login not required.
