This message appears in SSH logs when the SSH daemon (sshd) receives signal 15 (SIGTERM), a graceful termination request. It typically indicates a service restart or system shutdown, not necessarily a connection error.
Signal 15 (SIGTERM) is the standard termination signal in Unix/Linux systems. When you see "Received signal 15; terminating" in sshd logs or SSH output, it means the SSH daemon or a specific SSH connection received a graceful shutdown request. This is different from a hard kill (signal 9/SIGKILL)—SIGTERM allows the process to clean up resources and close connections properly before exiting. In most cases, this is normal behavior during service restarts or system shutdowns.
Determine whether the termination was intentional or unexpected by checking system logs:
# On systemd systems, check sshd logs:
sudo journalctl -u sshd --no-pager | tail -20
# Or check traditional auth logs:
sudo tail -20 /var/log/auth.log # Debian/Ubuntu
sudo tail -20 /var/log/secure # RHEL/CentOS/FedoraLook for messages before the "Received signal 15" entry. Look for:
- "Stopped OpenSSH server daemon" or "restarting SSH"
- System shutdown/reboot messages
- Resource-related warnings
- Package upgrade notifications
Check whether SSH is currently running and healthy:
# Check service status
sudo systemctl status sshd
# Or for non-systemd systems:
sudo service sshd statusExpected output should show:
- active (running) or running
- Recent restart timestamp (if recently restarted)
If SSH is NOT running:
# Start SSH service
sudo systemctl start sshd
# Or for non-systemd:
sudo service sshd start
# Verify it started
sudo systemctl status sshdIf SSH won't start after signal 15, there may be a configuration issue. Validate the SSH configuration:
# Test SSH configuration syntax
sudo sshd -t
# If there are errors, display them
sudo sshd -TIf the test reports errors, fix the configuration file:
sudo nano /etc/ssh/sshd_configCommon issues:
- Typo in parameter names (Port vs PORT)
- Invalid IP addresses in Listen directives
- Malformed authentication settings
- Missing or corrupted key files
After fixing, restart:
sudo systemctl restart sshdCheck if the signal 15 was triggered by recent activity:
# Check system uptime (indicates if system rebooted)
uptime
# Check last login times
last -5
# Check auth/system logs for recent changes
sudo grep -E "(ssh|reboot|shutdown)" /var/log/messages | tail -30
# Check if packages were recently updated
sudo apt list --upgradable # Debian/Ubuntu
sudo dnf check-update # Fedora/RHELIf you see SSH package upgrades around the time of signal 15, the termination was expected as part of the package update process.
If you see repeated "Received signal 15" messages, SSH may be stuck in a restart loop. Monitor it:
# Watch SSH service status in real-time
sudo watch -n 2 'systemctl status sshd | head -10'
# Or use journalctl with follow:
sudo journalctl -u sshd -fIf sshd keeps restarting:
1. Stop the service entirely:
sudo systemctl stop sshd
sudo systemctl disable sshd2. Fix the underlying issue (configuration error, missing keys, etc.)
3. Re-enable and start:
sudo systemctl enable sshd
sudo systemctl start sshdIf running sshd in a container (Docker, Kubernetes, etc.) and seeing repeated signal 15 messages:
Docker: Ensure proper signal handling in your Dockerfile:
FROM ubuntu:22.04
RUN apt-get update && apt-get install -y openssh-server
# Use exec form to ensure signals reach sshd
ENTRYPOINT ["/usr/sbin/sshd", "-D", "-e"]Kubernetes: Check if the pod is being terminated by the orchestrator:
kubectl get pods <pod-name> -o yaml | grep -A5 terminationGracePeriodSeconds
kubectl describe pod <pod-name> | grep -i signalFor container managers: Ensure termination grace period is sufficient for SSH to close connections gracefully.
Advanced troubleshooting:
Signal Handling and Process Managers: Different init systems (systemd, OpenRC, upstart) handle signal 15 differently. Systemd typically sends SIGTERM first with a configurable grace period (default 30 seconds), then SIGKILL if the process doesn't exit. Check TimeoutStopSec in your service file:
systemctl show -p TimeoutStopSec sshdSSH Key Rotation and Signal 15: Some systems perform key rotation on restart. If you see repeated signal 15 with no restart, check if key generation is failing:
sudo ssh-keygen -A # Regenerate missing keys
sudo systemctl restart sshdSystemd Service Dependencies: If another service depends on sshd and fails, it may cause cascading terminations. Check service dependencies:
systemctl list-dependencies sshd
systemctl list-dependencies --reverse sshdResource Exhaustion: On systems with extremely limited resources (embedded systems, containers with tight limits), signal 15 may appear if the kernel sends termination due to memory pressure or PID limits. Monitor resources:
free -h
ps aux | grep sshdLoad key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH