Why Ansible SSH Logins Do Not Appear in last

When administrators begin auditing Ansible activity on Linux servers, one question comes up frequently: if Ansible connects over SSH, why does that connection not appear in the output of the last command? A related concern is whether Ansible establishes a new SSH login for every task it runs.

The answer is straightforward. In most environments, this behavior is expected. Ansible typically uses SSH in a way that does not generate the login records that last relies on, and it often reuses existing SSH connections rather than opening a new one for every task.

Understanding What last Actually Shows

The last command reads from /var/log/wtmp, which stores records for interactive login sessions. These records are usually created when a user signs in through a normal shell session, whether locally or through a standard interactive SSH login.

Because of this, last is not a general-purpose audit tool for every SSH-based action. It is specifically designed to show login sessions that were recorded in the system’s login accounting files.

How Ansible Uses SSH

Ansible usually does not create a full interactive login session. Instead, it connects over SSH to execute commands directly on the remote host, much like the following example:

ssh user@host 'command'

This type of SSH invocation is non-interactive and non-login in nature. It opens a remote session for command execution, but it typically does not create the same utmp or wtmp records as a normal interactive shell. As a result, the connection often does not appear in last.

This explains the difference many administrators observe:

• A manual SSH login often appears in last.
• An Ansible-driven SSH command often does not.

The behavior is not a sign that Ansible failed to connect. It simply reflects how the operating system distinguishes between interactive logins and automated command execution.

See also: Mastering the Linux Command Line — Your Complete Free Training Guide

Where Ansible SSH Activity Is Actually Recorded

If the goal is to confirm that Ansible connected successfully, the correct place to look is the system’s SSH authentication logs rather than wtmp.

On Red Hat-based systems, these records are commonly stored in /var/log/secure. On Debian-based systems, they are usually stored in /var/log/auth.log.

For example:

# RHEL / CentOS
sudo grep sshd /var/log/secure | tail -50

# Debian / Ubuntu
sudo grep sshd /var/log/auth.log | tail -50

Typical entries may look like this:

sshd[12345]: Accepted password for tocao from 10.x.x.x port 54321 ssh2
sshd[12345]: pam_unix(sshd:session): session opened for user tocao

These log lines confirm that SSH authentication and session creation occurred, even if no entry appears in last.

Does Ansible Reconnect for Every Task?

Not necessarily. By default, Ansible is designed to reduce connection overhead by reusing SSH sessions when possible. It commonly relies on SSH multiplexing features such as ControlMaster and ControlPersist, and it may also use pipelining to improve efficiency.

This means that multiple tasks within the same play can often run over a shared SSH connection instead of requiring a fresh login each time. As a result, an Ansible playbook with many tasks may produce only a small number of authentication events in the SSH logs.

A typical configuration looks like this:

[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
pipelining = True

With this configuration, Ansible keeps the SSH connection alive briefly and reuses it across tasks, which improves performance and reduces repeated authentication.

Why This Matters for Auditing

From an auditing perspective, it is important to understand that last is not the right tool for tracking Ansible activity. If an administrator relies only on last, they may incorrectly conclude that no SSH access occurred.

For operational or security review, SSH daemon logs provide a more accurate source of truth. They record authentication events and session activity regardless of whether the session was interactive.

If more detailed accountability is required, administrators may also consider:

1. Disabling SSH connection reuse for clearer one-to-one logging behavior.
2. Reviewing PAM and lastlog configuration on the managed host.
3. Using centralized logging or session auditing tools for automation activity.

Conclusion

Ansible SSH sessions usually do not appear in last because last only displays login records written to /var/log/wtmp, and Ansible generally uses non-interactive SSH command execution that does not create those records. This is normal behavior and not a sign of failure.

To verify Ansible access, administrators should inspect SSH authentication logs such as /var/log/secure or /var/log/auth.log. They should also remember that Ansible often reuses SSH connections, so many tasks may be executed over a small number of authenticated sessions.