Monitor every SSH login on your servers

What each login record shows

Every server gets an SSH Logins tab with one row per session. Expand a row to see the session from login to logout.

• User - the account that logged in, root included
• Source IP - where the connection came from, with a trust verdict
• Login time - when the session opened
• Duration - how long the session stayed open
• Process count - how many processes ran in the session

A root session that ran 197 processes in two minutes reads differently from one that ran 11. A login notification only tells you someone arrived.

Click to expand

Recorded at the kernel, not by a login script

The agent sees each login with eBPF at the kernel and sends the session off the host as it happens. There is no PAM line to add and no script to copy onto every server. If someone gets root and edits /etc/pam.d/sshd, their login has already left the box. Session tracking is on for every server with security monitoring enabled, so the server you forgot about is covered too.

Trusted and untrusted sources

Tell AlertKick where logins should come from. The SSH allowed source IPs list holds your bastion hosts, office ranges, and home addresses, as single IPs or CIDR ranges. You set it once for the whole account, and every login gets one of three verdicts:

Untrusted logins page the engineer on call

When an SSH rule fires, AlertKick opens one alert per server and rule, and your escalation policy takes it from there. The engineer on call gets it by mobile push, Slack, SMS, WhatsApp, Telegram, or email, whichever the policy uses. Acknowledging from the phone stops the escalation. If nobody acknowledges, the policy pages the next person.

AI triage writes the alert text before it goes out, so the message says why the login looked wrong - outside business hours, unknown source, no deployment going on - and not just a bare IP address.

See how rosters and escalation policies work

No rules to write

The SSH rules ship with AlertKick under Security -> Rules. Each one is a toggle:

You set business hours once: timezone, start and end hour, and which days are workdays. A login from your CI runner at 14:00 on a Tuesday matches neither critical rule. Root from an unknown address at 02:00 matches both.

See what ran in the session

Turn on command capture for a server and the session timeline also lists the command line of each process the session ran. Arguments can hold passwords and tokens, so the agent redacts them on the host before anything leaves it. Redaction is best-effort, which is why capture is off by default and you choose the servers where it runs.

Lock SSH when nobody should be logging in

Most servers need interactive SSH for a few hours a month. SSH lockdown, on each server's Maintenance tab, denies new SSH logins outside the windows you set.

• Open a host for 15 minutes, 30 minutes, 1 hour, 4 hours, or a custom length. It locks itself again when the timer runs out.
• Recurring maintenance windows, such as Sundays 02:00-06:00.
• A bypass allowlist of IPs or CIDRs for your bastion and CI runner, which can always connect.
• A failsafe: if the agent loses contact with AlertKick for 10 minutes, the lock turns itself off. Console access is never blocked, and sessions already open stay open.

Logins during an open window still get session records and trust verdicts. Lockdown is also what Change Tracking & Control uses to open a host for an approved change and lock it again afterwards.

Set up in three steps

1. 01

   Add the server

   In the dashboard, go to Servers -> Add server.

2. 02

   Run one command

   Paste the install line into a root shell. It detects the distro and architecture and starts the agent under systemd.

3. 03

   Set hours and trusted IPs

   Add your business hours and allowed source IPs. Then SSH in from an address not on the list and watch the alert arrive.

# Copied from Servers -> Add server. Unique to each host.
curl -sSL 'https://app.alertkick.com/app/agent-install/<host-id>/script/<hash>?...' | sh

Debian, Ubuntu, RHEL, Rocky, Alma, Fedora, and others, on amd64 or arm64. The full walkthrough is in the install guide, and the rules are covered in the SSH login monitoring docs.

Related