How to fix error: Bind to port 22 on 0.0.0.0 failed: Address already in use. in SSH
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.
Quick fix
Fixes error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
sudo lsof -i :22- Check what process is using port 22
- Stop the existing SSH service
- Kill any remaining SSH processes
- Check sshd_config for conflicting ListenAddress directives
sudo lsof -i :22error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
What this error means
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.
Typical symptoms
- SSH service fails to start when running 'systemctl start sshd'
- Manual sshd startup produces the 'Address already in use' error message
- SSH connections timeout or refuse to connect
- Previous SSH sessions continue working but new connections fail
- After system reboot, SSH service fails to start automatically
Common causes
- Another sshd process is still running from a previous session or failed restart
- IPv6 and IPv4 dual-stack binding conflict where the IPv6 socket on :: is also accepting IPv4 connections
- sshd_config has multiple conflicting ListenAddress directives for the same port
- Kernel parameter net.ipv6.bindv6only is set to 0, causing IPv6 socket to claim port for both IPv4 and IPv6
- A different service or application has bound to port 22
- Port 22 is being held in TIME_WAIT state from a recent connection
How to fix "error: Bind to port 22 on 0.0.0.0 failed: Address already in use."
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.
Advanced notes
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.
Frequently asked questions
- What does "error: Bind to port 22 on 0.0.0.0 failed: Address already in use." mean?
- 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.
- How do I fix "error: Bind to port 22 on 0.0.0.0 failed: Address already in use."?
- 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.
- What causes "error: Bind to port 22 on 0.0.0.0 failed: Address already in use."?
- Another sshd process is still running from a previous session or failed restart IPv6 and IPv4 dual-stack binding conflict where the IPv6 socket on :: is also accepting IPv4 connections sshd_config has multiple conflicting ListenAddress directives for the same port
- Is the "error: Bind to port 22 on 0.0.0.0 failed: Address already in use." error serious?
- Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.