Fixing SSH Connection Hangs on Fedora 43 After Initial Port Contact

In Fedora 43, the transition to stricter System-Wide Crypto Policies and updated OpenSSH defaults can lead to a specific, frustrating failure: the connection successfully reaches the server's port but then hangs indefinitely with no error message. This usually happens immediately after the Connecting to <ip> port <port> message in verbose mode. Unlike a "Connection Refused" error, a hang suggests that the initial TCP handshake completed, but the subsequent Key Exchange (KEX) or MTU (Maximum Transmission Unit) negotiation is being silently dropped or throttled by the network stack or intermediate hardware.

Table of Content

• Purpose of Diagnostic Steps
• Common Use Cases
• Step by Step: Resolving the Hang
• Best Results for Stable Remote Access
• FAQ
• Disclaimer

Purpose

The primary purpose of this tutorial is to isolate whether the SSH stall is caused by Packet Fragmentation, Cipher Mismatches, or Firewall State Issues. Because Fedora 43 often defaults to the "FUTURE" or "DEFAULT" crypto-policy, older servers or specific router configurations may fail to process the larger packets used during modern key exchanges. We aim to identify the specific bottleneck in the handshake process to restore reliable CLI access.

Use Case

This troubleshooting guide is essential for:

• Remote Sysadmins: Connecting to legacy servers from a modern Fedora 43 workstation.
• VPN Users: Where the VPN overhead reduces the available MTU, causing large SSH packets to be dropped.
• Cloud Environments: Troubleshooting instances where Security Groups allow Port 22 but internal OS policies block specific handshake protocols.
• Home Lab Enthusiasts: Resolving issues after upgrading Fedora and finding that local SSH access has suddenly stopped working.

Step by Step

1. Run SSH in Triple Verbose Mode

To see exactly where the hang occurs, use the -vvv flag.
ssh -vvv user@ip-address
If the output stops after expecting SSH2_MSG_KEXINIT, the issue is likely related to MTU or Packet Fragmentation.

2. Adjust the MTU (The "Packet Size" Fix)

SSH handshake packets can be quite large. If your network cannot handle them, the connection will hang. Test this by temporarily lowering your interface MTU:
sudo ip link set dev eth0 mtu 1200
Try connecting again. If it works, the issue is "MTU Path Discovery" failing on your router.

3. Relax Fedora 43 Crypto-Policies

Fedora 43 may be attempting to use ciphers the server doesn't support. Try setting the policy to a more compatible level:
sudo update-crypto-policies --set DEFAULT:FEDORA43
Alternatively, try LEGACY if connecting to an ancient system (use with caution).

4. Disable IPV6 if Unused

Sometimes SSH hangs while waiting for an IPV6 timeout. Force IPV4 to see if the connection completes:
ssh -4 user@ip-address

5. Audit firewalld and SELinux

Ensure Fedora’s local firewall isn't "half-blocking" the return traffic. Temporarily test by stopping the service:
sudo systemctl stop firewalld
Check if SELinux is blocking the ssh-agent: ausearch -m avc -ts recent.

Best Results

FAQ

Why is there no error message?

Because the TCP connection is established, the client believes the connection is valid. It is waiting for a packet that the server has sent, but which was dropped by an intermediate router because it was too large to pass through without fragmentation.

Is Fedora 43 more restrictive?

Yes. Fedora 43 continues the trend of disabling SHA-1 and older RSA key lengths. If your server is more than 5 years old, you may need to explicitly enable these in ~/.ssh/config.

How do I make the MTU fix permanent?

Use NetworkManager: nmcli connection modify [ID] 802-3-ethernet.mtu 1492 followed by nmcli connection up [ID].

Disclaimer

Lowering crypto-policies to "LEGACY" reduces the security of your machine. Always prefer upgrading the remote server's OpenSSH version over weakening your client's security. This guide is based on the system architecture of Fedora 43 as released in 2026. Always ensure your system is fully patched with dnf update before troubleshooting hardware-level network issues.

Tags: Fedora43, SSH, Networking, OpenSSH