Why doesn't SSH work if WiFi is on while ethernet is connected?

SSH connections fail when both WiFi and ethernet are active because Linux prioritizes the wired interface for outbound traffic by default. The SSH client attempts to establish a connection via the Ethernet IP address, which may not be reachable from the remote server or may be blocked by firewall rules, while the intended path through WiFi is ignored due to routing table metrics.

The Root Cause: Routing Tables

Operating systems use a routing table to determine which network interface to use for outgoing packets. Each interface has a "metric" value that represents its cost; lower values indicate higher priority. In most Linux distributions, Ethernet interfaces (like eth0 or enp3s0) are assigned a lower metric than wireless interfaces (like wlan0). Consequently, when you initiate an SSH command, the system selects the Ethernet route. If your local network configuration does not allow direct access to the SSH server via the Ethernet subnet, or if the server is only accessible via the WiFi subnet, the connection will time out or refuse. This behavior is standard unless explicitly configured otherwise, leading to the common misconception that the services themselves are broken rather than the network path.

Diagnosing the Active Route

To confirm this is a routing issue, you must inspect how your system routes traffic. Open a terminal and run the following command to view the current IPv4 routing table:

ip route show

Look for lines starting with default. You will likely see two entries, one for each interface. The entry with the lowest metric number is the primary route. For example:

default via 192.168.1.1 dev eth0 proto dhcp metric 100
default via 192.168.2.1 dev wlan0 proto dhcp metric 600

In this scenario, all traffic, including SSH, defaults to eth0. If your target SSH server resides on the 192.168.2.x network (WiFi), the packet sent via eth0 will never reach it. You can also verify which interface the SSH client is using by running:

ssh -v user@host

Check the debug output for the source IP address being used. If it matches the Ethernet IP but the server expects the WiFi IP, the mismatch is confirmed. For more complex networking setups involving multiple gateways, understanding how the OS identifies interfaces is crucial. See Understanding the Meaning of Linux Thinks WiFi card as Ethernet Interface with Intel Wireless-AC9260 for details on interface naming conventions that might complicate manual routing configurations.

Solution 1: Adjusting Interface Metrics

The most permanent fix involves changing the metric of the WiFi interface to be lower than that of Ethernet, forcing the OS to prefer WiFi when both are connected. This requires editing the NetworkManager configuration files. First, identify the connection UUIDs for both your WiFi and Ethernet profiles using:

nmcli con show

Edit the WiFi connection profile to set a lower metric. Replace YOUR_WIFI_UUID with the actual UUID found in the previous step:

nmcli con mod YOUR_WIFI_UUID ipv4.route-metric 50

Similarly, ensure the Ethernet metric is higher, or leave it at the default. After making changes, reconnect both interfaces:

nmcli con up YOUR_WIFI_UUID
nmcli con down YOUR_ETHERNET_UUID
nmcli con up YOUR_ETHERNET_UUID

Verify the change with ip route show again. The WiFi route should now have the lower metric, directing SSH traffic through the wireless adapter. Note that if you are managing router-level access or different network segments, such as in embedded systems, refer to Grant LuCI Internet Access to OpenWRT Router/Switch to understand how gateway policies might override local host routing.

Solution 2: Using Policy-Based Routing

If you need simultaneous access to both networks without changing global priorities, policy-based routing allows you to send SSH traffic specifically through the WiFi interface. Create a new routing table file, for example, /etc/iproute2/rt_tables, and add a new entry:

echo "200 wifi" >> /etc/iproute2/rt_tables

Then, create a rule that directs traffic originating from your WiFi IP to use this new table. Assuming your WiFi IP is 192.168.2.10:

ip rule add from 192.168.2.10 table wifi
ip route add default via 192.168.2.1 dev wlan0 table wifi

This method is more robust for multi-homed hosts but requires careful management of persistent rules across reboots. It ensures that even if Ethernet is preferred for general internet browsing, SSH sessions initiated from the WiFi subnet remain stable.

Solution 3: Explicit Source Address in SSH

A quick workaround without altering system-wide settings is to specify the source address explicitly in the SSH command. This forces the kernel to bind the socket to the specific interface associated with that IP.

ssh -b 192.168.2.10 user@server_ip

Replace 192.168.2.10 with your local WiFi IP address. This tells the SSH client to use that specific local address as the source, effectively bypassing the default routing decision for that session. While effective for ad-hoc connections, this is tedious for daily use. You can automate this by adding an alias or a host-specific block in your ~/.ssh/config file. To check your current effective configuration and ensure no other overrides are interfering, you might want to Query effective ssh (client) config from command line to verify that the binding is applied correctly.

Preventing Future Conflicts

To avoid this issue entirely, consider disabling automatic connection for one interface when the other is active. In NetworkManager, go to the connection settings for WiFi, select the "General" tab, and uncheck "Automatically connect." Alternatively, use the "Use only when needed" option if available. This ensures that the routing table remains simple and predictable, reducing the likelihood of ambiguous paths causing connectivity failures during critical remote administration tasks.

Frequently Asked Questions

How do I check which interface my SSH connection is actually using?

You can determine the active interface by checking the source IP address of the connection. Run ss -tnp | grep ssh or netstat -tnp | grep ssh immediately after establishing the connection. Look for the local address column; the IP listed there corresponds to the interface the kernel selected for the outbound packet.

Can I make SSH work simultaneously over both interfaces?

Standard SSH does not support multiplexing over two distinct physical interfaces for a single session. However, you can maintain separate sessions: one bound to the Ethernet IP and another to the WiFi IP. Use the -b flag to bind specific clients to specific local addresses, allowing you to test connectivity on both paths independently.

Why does ping work but SSH fails on the same interface?

This usually indicates a firewall rule blocking port 22 while allowing ICMP (ping). Check your local iptables or ufw rules, as well as any intermediate firewalls. Ensure that inbound traffic on port 22 is permitted for the specific subnet associated with the active routing metric.

What happens if I disconnect the Ethernet cable while SSH is active?

If the routing table updates dynamically, the SSH session may drop because the underlying socket loses its network path. To prevent this, enable multipath TCP or use tools like mosh which handle network transitions better. Alternatively, ensure your SSH client has keep-alive settings enabled to detect drops quickly and attempt reconnection.

Is it safe to change the default gateway metric?

Yes, changing metrics is a standard administrative task. However, ensure you do not set conflicting metrics that cause routing loops. Always verify the routing table with ip route after making changes to guarantee that your default gateway points to the correct interface for your internet access needs.