Why Ansible SSH Logins Don’t Show in Last

Ansible SSH logins don’t appear in last because Ansible uses SSH’s exec channel (running a single command) rather than an interactive shell, and the session is not recorded as a login by utmp/wtmp. The last command reads /var/log/wtmp, which is only updated when a user logs in through a terminal (e.g., SSH with a pseudo-terminal) and then logs out. Ansible’s default connection method (ssh) opens a non-interactive SSH session that runs a remote command and immediately closes it, so no login record is written.

How Ansible Connects Over SSH

Ansible uses the ssh executable (or a Python SSH library like paramiko) to reach managed hosts. By default, it runs a single command per task, something like ssh host /bin/sh -c 'echo ~; echo ...'. This is a non-interactive SSH session: no TTY is allocated, and the remote process is not a login shell. The SSH server treats it as an exec request, not a session with a terminal. The utmp and wtmp files are only updated for login sessions (where a user gets a shell with a terminal), so the Ansible connection simply doesn’t trigger that code path.

What last Actually Shows

The last utility reads /var/log/wtmp, a binary file that records logins and logouts. Each entry contains the user, terminal, host, and timestamps. A login is recorded when the system’s login process or an SSH session with a pseudo-terminal (PTY) successfully authenticates and starts a session. For non-interactive commands, the SSH daemon does not allocate a PTY, and the session does not go through the login accounting routines. Therefore, no entry is written to wtmp, and last shows nothing.

Why You Might See Some Ansible Entries

There are a few scenarios where Ansible-related logins do appear in last:

• When you use ansible-playbook with --ask-pass and the ssh connection uses a PTY – but Ansible doesn’t allocate a PTY by default, so this is rare.
• If you explicitly set ansible_ssh_common_args: '-tt' – the -tt flag forces a TTY, which can cause the session to be recorded as a login. But that is unusual and not recommended for normal automation.
• If the remote host’s SSH server is configured to allocate a PTY for all sessions (e.g., ForceCommand with a PTY). That would be a non-standard setup.
• If you use a different connection plugin like paramiko with look_for_keys and it happens to allocate a TTY – again, not typical.

In most cases, the absence of Ansible in last is normal and expected.

How to See Ansible SSH Activity

If you need to audit Ansible connections, last is the wrong tool. Instead, check the SSH server logs:

• On the managed host, look at /var/log/auth.log (Debian/Ubuntu) or /var/log/secure (RHEL/CentOS). These files record every SSH authentication, including non-interactive ones. You’ll see entries like Accepted publickey for ansible from 192.0.2.10 port 52418 ssh2: RSA SHA256:....
• You can also use journalctl -u ssh on systemd-based systems to see recent SSH activity.
• For a real-time view, use sudo tail -f /var/log/auth.log while running an Ansible playbook.

These logs give you the exact time, user, and source IP of each Ansible connection.

Common Misconceptions

A frequent misunderstanding is that Ansible uses a “login” to run commands, so it should appear in last. But the SSH protocol distinguishes between interactive sessions (which allocate a PTY and are recorded) and exec requests (which run a single command without a PTY). Ansible uses the latter. Another misconception is that last shows all SSH connections – it doesn’t; it only shows logins that go through the login accounting system. Non-interactive commands are simply not logged there by design.

How to Make Ansible Sessions Appear in last (If You Really Want To)

If you have a specific compliance requirement that forces you to record Ansible sessions as logins, you can force a PTY allocation. In your Ansible inventory or playbook, set:

ansible_ssh_common_args: '-tt'

This adds the -tt flag to the SSH command, which forces a pseudo-terminal. As a result, the remote SSH server will treat the session as a login and write an entry to wtmp. However, this has downsides:

• It may cause warnings about “Pseudo-terminal will not be allocated because stdin is not a terminal.”
• It can break tasks that expect a non-interactive environment.
• It increases the overhead of each connection.

In practice, you should rely on auth.log rather than forcing PTYs, because that is the standard way to audit SSH activity.

Frequently Asked Questions

Does Ansible use SSH at all?

Yes, Ansible’s default connection plugin is ssh, which uses the OpenSSH client to connect to managed hosts. It can also use paramiko for pure-Python SSH, but the behavior regarding last is the same: non-interactive sessions aren’t logged.

Why does last show nothing for Ansible, but I see SSH connections in auth.log?

Because auth.log records all SSH authentication events, while wtmp only records interactive login sessions. Ansible’s SSH connections authenticate successfully (so they appear in auth.log) but they don’t start an interactive session, so they don’t appear in wtmp.

Can I see Ansible activity in last if I use sshpass?

No. sshpass only supplies a password to the SSH client; it doesn’t change the type of session. The connection is still non-interactive, so no wtmp entry is created.

Is there a way to make Ansible log to wtmp without forcing a TTY?

Not directly. The only way is to force a PTY allocation, which you can do with ansible_ssh_common_args: '-tt'. But as noted, this is discouraged because it can cause other issues.

Does Ansible’s become (sudo) affect last?

No. become changes the user on the remote host after the SSH connection is established, but the SSH session itself is still non-interactive. The sudo command may log to auth.log or its own log, but it doesn’t create a wtmp entry for the Ansible user.

Related

• Are Lenovo Laptops Good? Honest Guide
• SpaceX Public-Private Deep Space Program Plans
• Get Column Totals in Excel: 5 Quick Ways