This error occurs when the SSH daemon (sshd) cannot bind to port 22 because another process is already listening on it. Common causes include duplicate sshd instances, IPv6/IPv4 binding conflicts, or configuration issues.
The SSH daemon (sshd) attempted to start and bind to port 22, which is the standard port for SSH connections. However, the operating system rejected this request because port 22 is already in use by another process. This typically means either another sshd instance is running, or a different service has claimed the port. Port binding conflicts prevent the new service from accepting incoming connections on that port.
First, identify which process currently holds port 22. Use one of these commands:
sudo lsof -i :22Or with netstat:
sudo netstat -tulpn | grep :22Or with ss (modern systems):
sudo ss -tulpn | grep :22The output will show the process name and PID. If it shows sshd is already running, you likely have a duplicate process. If it's a different service, note that name.
Stop the currently running SSH service gracefully:
sudo systemctl stop sshdOr on older systems:
sudo service ssh stopWait a few seconds for the process to terminate. If it doesn't stop cleanly, check the next step.
If the service didn't stop cleanly, forcefully terminate the process:
sudo fuser -k 22/tcpOr using the PID from your earlier lsof/netstat output:
sudo kill -9 <PID>Verify the port is now free:
sudo lsof -i :22This should return no results.
Review your SSH configuration for issues:
sudo grep -n "ListenAddress\|Port" /etc/ssh/sshd_config | grep -v "^#"Look for:
- Multiple Port directives on the same line or repeated
- Multiple ListenAddress entries that could conflict
- ListenAddress directives pointing to non-existent IP addresses
If you find duplicates or invalid addresses, comment them out:
sudo nano /etc/ssh/sshd_configFor a basic setup, use just:
Port 22
ListenAddress 0.0.0.0
ListenAddress ::Always test your sshd configuration for syntax errors before restarting:
sudo sshd -tIf no output appears, the configuration is valid. If errors appear, fix them and repeat this test.
You can also do a dry-run start:
sudo sshd -t -DThis will attempt to bind to ports but won't daemonize.
Once configuration is validated and port 22 is free, restart sshd:
sudo systemctl start sshdOr:
sudo service ssh startVerify it's running:
sudo systemctl status sshdYou should see "active (running)" in the output.
Test that SSH is now accepting connections:
ssh -v localhostOr from a remote machine:
ssh user@your-server-ipIf the connection succeeds, the issue is resolved.
IPv6/IPv4 Dual-Stack Binding: By default, if sshd binds to the IPv6 address :: (all interfaces) with the net.ipv6.bindv6only kernel parameter set to 0 (the default), the IPv6 socket automatically accepts both IPv6 and IPv4 connections. This prevents a subsequent attempt to bind to 0.0.0.0 (IPv4 all interfaces). To resolve this, either: (1) Explicitly set ListenAddress 0.0.0.0 and ListenAddress :: to force separate sockets, or (2) Change the kernel parameter with 'sysctl -w net.ipv6.bindv6only=1', or (3) Disable IPv6 in sshd_config with ListenAddress 0.0.0.0 only. Alternative Port: If port 22 is reserved by another critical service, you can change SSH to run on an alternative port (e.g., 2222) by modifying Port in sshd_config. Remember to update firewall rules and document this change. TIME_WAIT State: On some systems, sockets remain in TIME_WAIT for 60 seconds after closure. If you just restarted sshd, wait a moment before checking if the port is truly free. Use 'ss -tpn' to see socket states.
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
How to fix SSH man-in-the-middle attack warning in SSH
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
How to fix "WARNING: UNPROTECTED PRIVATE KEY FILE!" in SSH
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
Bad owner or permissions on /home/user/.ssh/known_hosts
How to fix "Bad owner or permissions on known_hosts" in SSH
It is required that your private key files are NOT accessible by others.
How to fix "private key files are NOT accessible by others" in SSH