How to fix Received signal 15; terminating. in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026· 333 views

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.

Quick fix

Fixes Received signal 15; terminating.

# 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/Fedora
  1. Check system logs for context
  2. Verify SSH service status
  3. Check for configuration errors
  4. Review recent system changes
ssh — error
# 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/Fedora
Received signal 15; terminating.

What this error means

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.

Typical symptoms

  • SSH connection suddenly drops with 'Received signal 15; terminating' message
  • sshd daemon appears in logs terminating unexpectedly
  • Active SSH sessions disconnect abruptly
  • SSH service restarts appear in system logs
  • Multiple 'Received signal 15' messages if sshd restarts repeatedly

Common causes

  1. System is shutting down or rebooting normally
  2. Administrator manually restarted SSH service (systemctl restart sshd, service sshd restart)
  3. SSH package was updated and systemd automatically restarted the service
  4. Init system (systemd, init, upstart) sent termination signal to sshd
  5. System resource manager killed the process due to resource limits or constraints
  6. Service manager (like Docker, supervisor) sent termination signal to contained sshd
  7. Cron job or automated script triggered a service restart
  8. System timeout caused service to be terminated and restarted

How to fix "Received signal 15; terminating."

1Check system logs for context

Determine whether the termination was intentional or unexpected by checking system logs:

bash
# 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/Fedora

Look 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

2Verify SSH service status

Check whether SSH is currently running and healthy:

bash
# Check service status
sudo systemctl status sshd

# Or for non-systemd systems:
sudo service sshd status

Expected output should show:
- active (running) or running
- Recent restart timestamp (if recently restarted)

If SSH is NOT running:

bash
# Start SSH service
sudo systemctl start sshd

# Or for non-systemd:
sudo service sshd start

# Verify it started
sudo systemctl status sshd
3Check for configuration errors

If SSH won't start after signal 15, there may be a configuration issue. Validate the SSH configuration:

bash
# Test SSH configuration syntax
sudo sshd -t

# If there are errors, display them
sudo sshd -T

If the test reports errors, fix the configuration file:

bash
sudo nano /etc/ssh/sshd_config

Common 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:

bash
sudo systemctl restart sshd
4Review recent system changes

Check if the signal 15 was triggered by recent activity:

bash
# 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/RHEL

If you see SSH package upgrades around the time of signal 15, the termination was expected as part of the package update process.

5Monitor SSH restart loops

If you see repeated "Received signal 15" messages, SSH may be stuck in a restart loop. Monitor it:

bash
# 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 -f

If sshd keeps restarting:

1. Stop the service entirely:

bash
sudo systemctl stop sshd
sudo systemctl disable sshd

2. Fix the underlying issue (configuration error, missing keys, etc.)

3. Re-enable and start:

bash
sudo systemctl enable sshd
sudo systemctl start sshd
6For containerized SSH environments

If running sshd in a container (Docker, Kubernetes, etc.) and seeing repeated signal 15 messages:

Docker: Ensure proper signal handling in your Dockerfile:

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:

bash
kubectl get pods <pod-name> -o yaml | grep -A5 terminationGracePeriodSeconds
kubectl describe pod <pod-name> | grep -i signal

For container managers: Ensure termination grace period is sufficient for SSH to close connections gracefully.

Advanced notes

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:

bash
systemctl show -p TimeoutStopSec sshd

SSH 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:

bash
sudo ssh-keygen -A  # Regenerate missing keys
sudo systemctl restart sshd

Systemd Service Dependencies: If another service depends on sshd and fails, it may cause cascading terminations. Check service dependencies:

bash
systemctl list-dependencies sshd
systemctl list-dependencies --reverse sshd

Resource 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:

bash
free -h
ps aux | grep sshd

Frequently asked questions

What does "Received signal 15; terminating." mean?
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.
How do I fix "Received signal 15; terminating."?
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.
What causes "Received signal 15; terminating."?
System is shutting down or rebooting normally Administrator manually restarted SSH service (systemctl restart sshd, service sshd restart) SSH package was updated and systemd automatically restarted the service
Is the "Received signal 15; terminating." error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading