Error: Kex_Exchange_Identification: Connection Closed by Remote Host [Top 11 Troubleshooting Tricks]
I know how stressful it feels when you try to SSH into a server and an error: kex_exchange_identification: connection closed by remote host occurred. It happens during the key exchange (KEX) phase of SSH authentication. It means the remote server ended the connection before SSH could finish.
According to the GitHub SSH troubleshooting guide, it usually occurs because of firewalls, IP blocks, or SSH limits. As an Exchange admin with more than 10+ years of experience, I faced this challenge many times. But I resolved this issue every time.
Today, I’ll share my 11 troubleshooting solutions to fix this issue in seconds. So, let’s understand the reasons behind this!
Root Causes Behind Error: Kex_Exchange_Identification: Connection Closed by Remote Host
As I experienced this issue personally, I’m very well known about the factors that lead to this, i.e.
- Firewall or security group blocking SSH.
- SSH daemon (sshd) not running.
- The server allows only specific IPs.
- Too many active SSH connections.
- Host key or sshd_config misconfiguration.
- DNS resolution failure.
- The server is out of CPU or memory.
- OpenSSH PerSourcePenalties blocking the source.
- Corporate or cloud network blocking port 22 (use port 443 for GitHub).
After reviewing these reasons, if you identify one that applies to your case and want to fix it, follow these quick troubleshooting steps:
- Check the firewall and open port 22
- Verify the sshd service is running
- Confirm server IP allowlist
- Reduce active SSH connections
- Clear known_hosts entry or fix sshd_config
- Test with server IP instead of hostname
- Free up CPU and memory
- Adjust the OpenSSH PerSourcePenalties setting
- Try SSH on port 443 if 22 is blocked
Still, if you a detailed steps, then no issues. I’ll explain each of them in detail simply.
Related article: Find Exchange Server Version
How to Fix Error: Kex_Exchange_Identification: Connection Closed by Remote Host?
Here are the 11 troubleshooting solutions with detailed step-by-step instructions to fix the issue in seconds:
#1. Check if the SSH Service is Running
On the remote host, run:
sudo systemctl status ssh
or
sudo systemctl status sshd
If it is not running, then start it:
sudo systemctl start ssh sudo systemctl enable ssh
#2. Verify Firewall Rules
On Linux, check if port 22 is open:
Sudo ufw status
If blocked, enable it:
Sudo ufw allow ssh
On AWS, Azure, or GCP, you have to update security group/firewall rules to allow inbound traffic on port 22.
#3. Clear Old Host Keys
Sometimes, SSH refused connections because of mismatched host keys. So, remove the old entry by running this command:
ssh-keygen -R <hostname or IP>
This will resolve the error: kex_exchange_identification: connection closed by remote host instantly.
#4. Check IP Restrictions and Fail2Ban
On the server, look at /etc/hosts.allow and /etc/hosts.deny. If your IP isn’t allowed, add it.
Also, check Fail2Ban to see if you blocked:
sudo fail2ban-client status sshd sudo fail2ban-client set sshd unbanip <MY_IP>
#5. Increase Connection Limits
Busy servers sometimes hit SSH limits. So, update /etc/ssh/sshd_config:
MaxSessions 50
MaxStartups 50:30:200
Then restart SSH:
sudo systemctl restart ssh
#6. Adjust PerSourcePenalties (2025 Updated in OpenSSH)
Recent OpenSSH versions introduced PerSourcePenalties, which can refuse new connections from an IP.
If you saw this behaviour, disable or relax the setting in /etc/ssh/sshd_config:
PerSourcePenalties no
Then reloaded SSH.
#7. Regenerate Missing Host Keys
If sshd accepted TCP but dropped connections before KEX, it means the host keys are missing. Fix error: kex_exchange_identification: connection closed by remote host by running:
sudo ssh-keygen -A sudo systemctl restart ssh
#8. Fix Network or Port Issues
When connecting to GitHub from a restricted network, always use SSH over port 443. Additionally, add this to your SSH config (~/.ssh/config):
Host github.com Hostname ssh.github.com Port 443 User git
#9. Prevent Ephemeral Port Exhaustion
On high-load servers, adjust ephemeral port settings:
sudo sysctl -w net.ipv4.ip_local_port_range="1024 65000" sudo sysctl -w net.ipv4.tcp_tw_reuse=1
#10. Check Logs for More Clues
The most helpful step is checking logs:
sudo journalctl -u ssh sudo tail -f /var/log/auth.log
#11. Test with Verbose Mode
For more details, run:
ssh -vvv user@server_ip
Also read: How to Upgrade Exchange 2013 to 2016
How to Avoid Error: Kex_Exchange_Identification: Connection Closed by Remote Host in Future
Many users asked me that “Is it possible to fix this error permanently?” So, my answer was no, because the mistakes we discussed previously, which led to this issue, are commonly made by humans accidentally.
Still, now you know the causes behind this, so don’t repeat the same mistakes to avoid this issue in future.
I suggest minimising dependency on SSH for migrations. Instead, opt for SysTools Exchange Migrator for effortless transfers. This software helps to move data simultaneously with advanced filters.
So, why take the headache with SSH, just download this for free, and move even large files in minutes, hassle-free!
Author’s Verdict
The error: kex_exchange_identification: connection closed by remote host means the SSH process is interrupted before authentication. I was shared all the fixes and causes behind this issue.
People Also Ask
Q. Can Fail2Ban cause this error?
Yes. If Fail2Ban bans your IP after multiple failed logins, SSH will drop your connection. You can check and unban your IP with:
sudo fail2ban-client status sshd sudo fail2ban-client set sshd unbanip <YOUR_IP>
Q. Is it possible to migrate shared mailbox to Office 365 via SSH?
No, you can’t, as mailbox migration requires Exchange or third-party migration tools, not remote shell connections.
Q. What are PerSourcePenalties in OpenSSH?
It’s a newer feature in OpenSSH that temporarily refuses new connections from a client IP if it behaves suspiciously.
Q. Can missing SSH host keys cause this error: kex_exchange_identification: connection closed by remote host?
Yes. If server host keys are missing or corrupt, sshd may accept TCP but close the session.