When troubleshooting slow SSH logins, the key smoking gun appears in your auth logs:

pam_systemd(sshd:session): Failed to create session: 
Activation of org.freedesktop.login1 timed out

The delay occurs because SSH's PAM stack tries to communicate with systemd-logind through D-Bus to:

• Create a new session scope
• Set up user process tracking
• Manage seat assignments

Check logind's health status:

systemctl status systemd-logind.service
journalctl -u systemd-logind --since "1 hour ago"

Strace reveals the actual blockage point:

ppoll([{fd=5, events=POLLIN}], 1, {24, 999645000}, NULL, 8) = 1 
([{fd=5, revents=POLLIN}], left {0, 0}) <25.020764>

Option 1: Adjust login timeout (recommended)

# /etc/systemd/logind.conf
[Login]
RuntimeDirectorySize=10M
SessionTimeout=30s

Option 2: Disable systemd integration for SSH

# /etc/pam.d/sshd
# Comment out this line:
# session    required     pam_systemd.so

Option 3: Patch the D-Bus configuration

# /etc/dbus-1/system.d/org.freedesktop.login1.conf
<policy context="default">
    <allow send_destination="org.freedesktop.login1"/>
</policy>

Create a watchdog script:

#!/bin/bash
TIMEOUT=$(systemctl show -p TimeoutStartUSec systemd-logind | cut -d= -f2)
if [[ $TIMEOUT -gt 30000000 ]]; then
    systemctl restart systemd-logind
    logger "Restarted systemd-logind due to timeout threshold"
fi

The issue typically appears when:

• D-Bus message queue gets overloaded
• Systemd-logind loses track of active sessions
• There's a mismatch between PAM and systemd versions

---

When establishing SSH connections to certain Linux servers running systemd, you might encounter an unusual 25-second delay during authentication. The strace output reveals a critical timeout:

ppoll([{fd=5, events=POLLIN}], 1, {24, 999645000}, NULL, 8) = 1 ([{fd=5, revents=POLLIN}], left {0, 0}) <25.020764>

This issue stems from interaction between three key components:

• OpenSSH server (sshd)
• PAM (pluggable authentication modules)
• systemd-logind service (DBus interface org.freedesktop.login1)

To confirm this is your issue, check these logs:

# Check auth logs
sudo grep "pam_systemd" /var/log/auth.log

# Examine systemd-logind status
journalctl -u systemd-logind --since "1 hour ago"

You'll typically see entries like:

pam_systemd(sshd:session): Failed to create session: Activation of org.freedesktop.login1 timed out

The timeout occurs when:

1. SSH authenticates a user via PAM
2. pam_systemd attempts to create a session through DBus
3. The systemd-logind service is unresponsive to DBus requests
4. The default 25-second timeout elapses before falling back

Restarting the service provides temporary relief:

sudo systemctl restart systemd-logind.service

Option 1: Disable session tracking (not recommended)

Edit /etc/pam.d/sshd and comment out:

# session    required     pam_systemd.so

Option 2: Systemd configuration tuning

Create /etc/systemd/system/systemd-logind.service.d/timeout.conf:

[Service]
TimeoutStartSec=10
Restart=on-failure
RestartSec=5s

Then reload:

sudo systemctl daemon-reload
sudo systemctl restart systemd-logind

Option 3: SSH configuration adjustment

Add to /etc/ssh/sshd_config:

UsePAM no
UseDNS no

Create a watchdog script /usr/local/bin/check_logind.sh:

#!/bin/bash
if ! systemctl is-active --quiet systemd-logind; then
    systemctl restart systemd-logind
    echo "$(date) - Restarted systemd-logind" >> /var/log/logind_watchdog.log
fi

Set up a cron job:

*/5 * * * * root /usr/local/bin/check_logind.sh

For deeper investigation, enable debug logging:

# For systemd-logind
sudo mkdir -p /etc/systemd/system/systemd-logind.service.d/
echo -e "[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug" | sudo tee /etc/systemd/system/systemd-logind.service.d/debug.conf

# For DBus
echo -e "[Service]\nEnvironment=DBUS_VERBOSE=1" | sudo tee /etc/systemd/system/dbus.service.d/debug.conf

sudo systemctl daemon-reload
sudo systemctl restart systemd-logind dbus

This issue particularly affects:

• Debian Jessie (8.x) systems
• systemd versions 215-217
• OpenSSH versions 6.7p1-5+deb8u3

The Debian bug tracker contains relevant discussion at bug #770135.