SSH (Secure Shell) logs are crucial for monitoring and maintaining the security and performance of systems that use SSH for remote management. SSH logs are typically recorded by the SSH daemon (sshd), which is responsible for handling incoming SSH connections. These logs can provide insights into user activity, connection attempts, authentication successes and failures, and other relevant events. Monitoring these logs is essential for detecting unauthorized access attempts, troubleshooting issues, and ensuring compliance with security policies.

Here's an example of a typical SSH log entry:

Jul 17 09:23:45 server1 sshd[1234]: Accepted publickey for user1 from 192.168.1.100 port 52413 ssh2: RSA SHA256:abcdefghijklmnopqrstuvwxyz123456789ABCDEFG

This log entry contains valuable information such as the timestamp, server name, process ID, authentication method, username, source IP address, port number, and the type of encryption key used. By analyzing these logs, system administrators can track user access, identify potential security threats, and maintain a secure SSH environment.

Key Elements of SSH Logs

SSH logs contain various types of information, each serving a different purpose in understanding and managing SSH activity. The key elements typically found in SSH logs include:

  1. Timestamp:
    • Indicates the date and time when the log entry was recorded.
    • Example: Jul 12 08:23:45
  2. Hostname:
    • The name of the host machine where the SSH daemon is running.
    • Example: server1
  3. Process Name:
    • The name of the process that generated the log entry, usually sshd.
    • Example: sshd
  4. Process ID (PID):
    • The process ID of the SSH daemon instance that generated the log entry.
    • Example: 1234
  5. Event Type:
    • Describes the type of event being logged, such as an authentication attempt, session start, or session end.
    • Common event types include Accepted, Failed, Disconnected, session opened, and session closed.

We will later see a breakdown of these elements in actual SSH logs examples.

Accessing SSH Logs

SSH logs are essential for monitoring the security and activity of SSH connections on your system. They can be accessed using various methods, depending on your system's logging setup and distribution. Below are some common ways to access SSH logs on Linux systems.

Using journalctl

journalctl is a command used to view logs managed by systemd, which is the system and service manager used in many modern Linux distributions like Ubuntu, CentOS, and Debian.

On systems that use systemd, such as modern versions of Ubuntu, CentOS, and Debian, SSH logs are managed by the journald service. The journalctl command is used to access these logs.

To view SSH logs specifically, you can use:

journalctl -u ssh

This command filters the logs to show entries related to the SSH service. You can further refine your search by adding time ranges or other filters. For example:

journalctl -u ssh --since "2023-07-01" --until "2023-07-12"

Accessing /var/log/auth.log

On some systems, especially older ones or those that do not use systemd, SSH logs are recorded in the /var/log/auth.log file. This is common in older versions of Debian, Ubuntu, and other distributions that use SysVinit or other init systems.

To view the SSH logs in /var/log/auth.log, you can use common text file viewing commands such as cat, less, or tail.

For example:

tail -f /var/log/auth.log

Or to search for specific SSH-related entries:

grep sshd /var/log/auth.log

Other common commands for viewing logs

Apart from journalctl and direct access to /var/log/auth.log, there are other commands and tools you can use to view and manage SSH logs:

  1. cat:

    cat /var/log/auth.log
    
  2. less:

    less /var/log/auth.log
    
  3. grep:

    grep sshd /var/log/auth.log
    
  4. tail:

    tail -f /var/log/auth.log
    
  5. rsyslog or syslog-ng:

    • These are logging daemons that may be configured to direct SSH logs to specific files or remote logging servers.
  • SSH Logs on Ubuntu: Modern versions use journalctl, but older versions use /var/log/auth.log.
  • SSH Logs on CentOS: Similar to Ubuntu, modern CentOS uses journalctl, while older versions might use /var/log/secure.
  • SSH Logs on Debian: Follows the same pattern as Ubuntu, using journalctl in modern versions and /var/log/auth.log in older versions.
  • SSH Logs on Linux: Generally, modern Linux distributions with systemd use journalctl. Older distributions or those using other init systems use specific log files like /var/log/auth.log or /var/log/secure.
  • SSH Logs on Windows: Windows does not natively support SSH in the same way as Linux. However, with OpenSSH installed on Windows, logs can be accessed through Event Viewer or specific log files in the OpenSSH installation directory.

Interpreting SSH Logs

SSH logs contain detailed information about SSH connections to your server. Understanding these logs is crucial for monitoring access and maintaining security. Let's break down the key types of log entries you might encounter.

Log Entries

SSH logs typically include information such as timestamps, user information, IP addresses, and the outcome of login attempts. These logs can be found using journalctl on modern systems or in /var/log/auth.log on older systems.

Successful Login and Failed Login Attempts

A successful login attempt log entry indicates that a user has successfully authenticated and gained access to the server.

Example:

Jul 12 08:23:45 server1 sshd[1234]: Accepted password for user1 from 192.168.1.100 port 22 ssh2

Breakdown:

  • Timestamp: Jul 12 08:23:45 – The date and time of the login attempt.
  • Hostname: server1 – The name of the server where the login occurred.
  • Process Name and ID: sshd[1234] – The SSH daemon process and its ID.
  • Event Type: Accepted password – Indicates a successful password authentication.
  • User: user1 – The username of the person who logged in.
  • Remote Host: 192.168.1.100 – The IP address of the remote client.
  • Port: 22 – The port number used for the SSH connection.
  • Protocol: ssh2 – The SSH protocol version used.

A failed login attempt log entry indicates that a user tried to log in but failed to authenticate. This can happen for various reasons, such as incorrect passwords or attempts to log in with invalid usernames.

Example:

Jul 12 08:24:10 server1 sshd[1234]: Failed password for invalid user fakeuser from 192.168.1.100 port 22 ssh2

Breakdown:

  • Timestamp: Jul 12 08:24:10 – The date and time of the login attempt.
  • Hostname: server1 – The name of the server where the login attempt occurred.
  • Process Name and ID: sshd[1234] – The SSH daemon process and its ID.
  • Event Type: Failed password – Indicates a failed password authentication attempt.
  • User: invalid user fakeuser – Shows that an invalid username was used.
  • Remote Host: 192.168.1.100 – The IP address of the remote client.
  • Port: 22 – The port number used for the SSH connection.
  • Protocol: ssh2 – The SSH protocol version used.

Log Management

Effective log management is crucial for maintaining the security and performance of your SSH-enabled systems. Here's a guide on securing SSH access, setting log levels, filtering logs, real-time monitoring, and using lastlog.

Securing SSH Access

  1. Restrict SSH Access:
    • Allow Specific Users: Edit the /etc/ssh/sshd_config file to allow only specific users to log in via SSH:

      AllowUsers user1 user2
      
    • Disable Root Login: It’s a good security practice to disable root login via SSH:

      PermitRootLogin no
      
  2. Use Key-Based Authentication:
    • Generate an SSH key pair on your local machine:

      ssh-keygen
      
    • Copy the public key to the remote server:

      ssh-copy-id user@remote_server
      
    • Disable password authentication in the /etc/ssh/sshd_config file:

      PasswordAuthentication no
      
  3. Change the Default SSH Port:
    • Edit the /etc/ssh/sshd_config file to use a non-standard port:

      Port 2222
      
    • Restart the SSH service:

      sudo systemctl restart ssh
      

Setting Log Levels for SSHD

Adjusting the log level in SSH can help you capture more detailed information or reduce log verbosity.

  1. Edit the SSH Configuration File:
    • Open /etc/ssh/sshd_config in a text editor:

      sudo nano /etc/ssh/sshd_config
      
    • Find and modify the LogLevel directive. Available options include QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3:

      LogLevel INFO
      
    • Save the changes and restart SSH:

      sudo systemctl restart ssh
      

Filtering Logs

Use journalctl to filter logs by different parameters.

  1. By Date/Time:
    • To view logs since a specific date:

      journalctl -u ssh --since "2023-07-01"
      
    • To view logs within a date range:

      journalctl -u ssh --since "2023-07-01" --until "2023-07-12"
      
  2. By Priority:
    • To view logs of a specific priority (e.g., errors):

      journalctl -u ssh -p err
      

Real-time Log Monitoring

To monitor SSH logs in real-time, you can use journalctl or tail.

  1. Using journalctl:

    journalctl -u ssh -f
    
  2. Using tail (for older systems that log to /var/log/auth.log):

    tail -f /var/log/auth.log
    

Using lastlog

lastlog is a command-line utility that displays the most recent login of all users or a specific user on the system.

  1. View All Users' Last Login:

    lastlog
    
  2. View a Specific User's Last Login:

    lastlog -u username
    

Send Logs to SigNoz

SigNoz is an open-source observability platform that can ingest and analyze logs from various sources. Here's how to send logs to SigNoz:

  1. SetUp SigNoz

    SigNoz cloud is the easiest way to run SigNoz. Sign up for a free account and get 30 days of unlimited access to all features. Get Started - Free
CTA You can also install and self-host SigNoz yourself since it is open-source. With 18,000+ GitHub stars, open-source SigNoz is loved by developers. Find the instructions to self-host SigNoz.

  2. Install OpenTelemetry Collector: Download and install the OpenTelemetry Collector on your system.

  3. Configure the Collector: Create a configuration file (e.g., otel-collector-config.yaml) with the following structure:

    receivers:
      filelog:
        include: [ /path/to/your/logfile ]
        start_at: end
    processors:
      batch:
    exporters:
      otlp:
        endpoint: <SigNoz-Backend-URL>
        tls:
          insecure: false
        headers:
          "signoz-access-token": <SIGNOZ_INGESTION_KEY>
      logging:
        verbosity: normal
    service:
      pipelines:
        logs:
          receivers: [filelog]
          processors: [batch]
          exporters: [otlp]
    
    

    Replace <SigNoz-Backend-URL> and <SIGNOZ_INGESTION_KEY> with your SigNoz instance URL and ingestion key.

  4. Start the Collector: Run the OpenTelemetry Collector with your configuration.

  5. Configure SigNoz: In the SigNoz UI, set up log management and create a new log source.

  6. View and Analyze Logs: Use SigNoz's dashboard to view, search, and analyze your logs.

SigNoz Log Management
SigNoz Log Management

By sending logs to SigNoz, you can centralize log management, set up alerts, and correlate logs with other telemetry data in your infrastructure.

Conclusion

  • Secure SSH Access: Implement best practices like restricting user access, disabling root login, using key-based authentication, and changing the default SSH port to enhance security.
  • Set Log Levels: Adjust the log verbosity in the SSH configuration file to capture the necessary level of detail for monitoring and troubleshooting.
  • Filter Logs: Utilize journalctl to filter SSH logs by date, time, and priority to efficiently find relevant log entries.
  • Real-time Monitoring: Monitor SSH logs in real-time using journalctl -f or tail -f to promptly detect and respond to security events.
  • Use lastlog: Leverage the lastlog command to track the most recent logins of all users or specific users, aiding in security audits and investigations.

FAQs

What are SSH logs?

SSH logs are records of events related to SSH (Secure Shell) connections, including successful and failed login attempts, connection details, and session activities.

How to track SSH logins?

Use the journalctl -u ssh command on modern Linux systems or check /var/log/auth.log on older systems. The lastlog command can also be used to track the last login of users.

How to check SSH logs in Windows?

On Windows with OpenSSH installed, SSH logs can be accessed through the Event Viewer under "Windows Logs" > "Applications and Services Logs" > "OpenSSH".

How to view SSH logs in Ubuntu?

Use journalctl -u ssh for modern versions with systemd or check /var/log/auth.log on older versions.

What is SSH used for?

SSH is used for secure remote access to servers and devices, enabling encrypted communication and command execution over a network.

What is SSH and SSL?

SSH (Secure Shell) is a protocol for secure remote login and other secure network services. SSL (Secure Sockets Layer) is a protocol for securing data transmission over the internet.

How to log into SSH?

Use the ssh username@hostname command in a terminal, replacing username with your user name and hostname with the server's address.

Can SSH be tracked?

Yes, SSH can be tracked using logs that record connection attempts, login successes and failures, and other related events.

Where are OpenSSH logs?

On most systems, OpenSSH logs are found in /var/log/auth.log or can be accessed via journalctl -u ssh on systems using systemd.

What is the default LogLevel for SSH?

The default LogLevel for SSH is INFO, providing a balance between verbosity and relevance of logged information.

What is SSH audit?

SSH audit is the process of reviewing SSH logs and configurations to ensure security policies are being followed and to detect any unauthorized access or anomalies.

Where is the SSH debug log?

To enable SSH debug logging, use the -d flag when starting the SSH server (sshd -d). Logs will typically appear in the same location as other SSH logs, such as /var/log/auth.log or via journalctl.

Was this page helpful?