Bug: asyncssh DNS resolution fails in container while system resolver works

[aenertia]

Bug: asyncssh DNS resolution fails in container while system resolver works

Component

linux-mcp-server container image (quay.io/redhat-services-prod/rhel-lightspeed-tenant/linux-mcp-server:latest)

Version

• linux-mcp-server: linux-diagnostics v2.14.5
• asyncssh: 2.22.0
• Container base: Python 3.12 (UBI)
• Host: RHEL 10.1 (awa.3d.ae.net.nz), podman 5.6.0, kernel 6.12

Summary

All tools fail with [Errno -2] Name or service not known when using the host parameter for remote SSH diagnostics. The error originates from asyncssh's DNS resolution, not the system resolver. Standard socket.getaddrinfo() and openssh both resolve and connect successfully from the same container.

Steps to Reproduce

1. Deploy linux-mcp-server as a podman container with streamable-http transport:

podman run --name linux-mcp-server --network=host \
    -e LINUX_MCP_TRANSPORT=streamable-http \
    -e LINUX_MCP_HOST=0.0.0.0 \
    -v /path/to/ssh/id_ed25519:/var/lib/mcp/.ssh/id_ed25519:ro \
    -v /path/to/ssh/config:/var/lib/mcp/.ssh/config:ro \
    -v /path/to/ssh/known_hosts:/var/lib/mcp/.ssh/known_hosts:rw \
    -v /path/to/logs:/var/lib/mcp/.local/share/linux-mcp-server/logs:rw \
    quay.io/redhat-services-prod/rhel-lightspeed-tenant/linux-mcp-server:latest

2. Confirm SSH works from inside the container:

podman exec linux-mcp-server ssh -o StrictHostKeyChecking=accept-new aenertia@target-host.example.com hostname
# Returns: target-host.example.com   ← SUCCESS

3. Confirm Python DNS resolution works:

podman exec linux-mcp-server python3 -c "
import asyncio, socket
loop = asyncio.new_event_loop()
print(loop.run_until_complete(loop.getaddrinfo('target-host.example.com', 22)))
"
# Returns: [(<AddressFamily.AF_INET6: 10>, ...)]   ← SUCCESS

4. Confirm TCP connectivity works:

podman exec linux-mcp-server python3 -c "
import socket
s = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
s.settimeout(5)
s.connect(('fd15:af69:ba1::ba5e', 22))
print('CONNECTED')
s.close()
"
# Returns: CONNECTED   ← SUCCESS

5. Call any tool via MCP with a host parameter:

{"jsonrpc":"2.0","id":3,"method":"tools/call","params":{
  "name":"get_system_information",
  "arguments":{"host":"aenertia@target-host.example.com"}
}}

Expected Result

Tool executes the command on the remote host via SSH and returns system information.

Actual Result

Instant failure (0.003s):

Error calling tool 'get_system_information': [Errno -2] Name or service not known

Server logs show:

INFO  | linux-mcp-server | TOOL_CALL: get_system_information | execution_mode=REMOTE | host=aenertia@target-host.example.com
WARNING | linux-mcp-server | SSH host key verification disabled - vulnerable to MITM attacks
INFO  | asyncssh | Host canonicalization disabled
INFO  | asyncssh | Opening SSH connection to aenertia@target-host.example.com, port 22
ERROR | linux-mcp-server | TOOL_COMPLETE: get_system_information | error: [Errno -2] Name or service not known | duration=0:00:00.002912s

Analysis

• The error is socket.gaierror: [Errno -2] Name or service not known from asyncssh's internal connection logic
• socket.getaddrinfo() works correctly from the same Python runtime in the same container
• OpenSSH ssh command works correctly from the same container
• TCP socket connect to the resolved IP works correctly
• The failure is instant (2.9ms) — asyncssh is not even attempting a TCP connection
• Tested with both --network=host and --network=<bridge> — same result
• Tested with --add-host entries in /etc/hosts — same result
• Tested with IPv6 ULA addresses, IPv6 global addresses, and FQDNs — same result
• The issue appears to be in how asyncssh resolves hostnames internally, possibly related to the container's NSS configuration or asyncio event loop DNS resolution path

Workaround

None found. The SSH remote execution feature is completely non-functional in the container image.

Environment Details

• Host OS: RHEL 10.1 (kernel 6.12.0-124.9.1.el10_1.x86_64)
• Container runtime: podman 5.6.0
• Network: tested both bridge (podman network with DNS enabled) and host
• Target hosts: RHEL 10.1 (koero) — working sshd, key auth confirmed
• SSH auth: ed25519 key, key-based auth confirmed working via openssh from same container