Plink Access Granted: Nothing Occurs Even with Correct Credentials?

Plink grants access without data transfer when the SSH session initializes but fails to establish a functional channel for command execution or file transfer. This usually stems from server-side configuration issues, such as restricted shell environments, firewall rules blocking specific ports, or authentication methods that succeed but do not grant interactive privileges. Verifying the remote shell configuration and network path is essential to resolve this silent failure.

Understanding the Silent Failure

When Plink reports success, it means the transport layer encryption has been established and the user credentials were accepted by the SSH daemon. However, "access granted" only confirms identity, not capability. If no data moves after login, the session is effectively deadlocked. This phenomenon often confuses users who assume that successful authentication guarantees a working terminal or SFTP subsystem. The disconnect typically occurs between the initial handshake and the actual allocation of a pseudo-terminal or data stream. You must distinguish between a connection that hangs indefinitely and one that opens briefly then closes. A hang suggests a network blockage or a waiting state on the server side, while an immediate close indicates a rejection of the requested service. In many cases, the server allows the login but refuses to start a shell due to restrictive configurations. This is common in automated accounts or restricted environments where interactive sessions are explicitly disabled. Understanding this distinction helps narrow down whether the problem lies in the network infrastructure or the server's permission settings.

Server-Side Configuration Checks

The most frequent cause of this issue is the ForceCommand directive in the sshd_config file. Administrators often use this setting to restrict users to specific scripts or commands, which can inadvertently break standard interactive shells. If the forced command exits immediately or waits for input that never arrives, the client appears to hang. Additionally, check if the user’s home directory or authorized keys file has incorrect permissions. SSH is strict about file ownership and modes; if .ssh/authorized_keys is writable by group or others, the server may silently ignore it or fall back to password authentication, which might behave differently depending on the client setup. Another critical area is the shell definition itself. Ensure that the user account has a valid login shell assigned in /etc/passwd. If the shell path points to a non-existent binary or a script that fails to initialize, the session will terminate quietly. You can verify this by attempting to log in with verbose mode enabled. Look for messages indicating that the shell could not be executed or that the terminal type was rejected. These errors often appear in the server’s system logs rather than the client output, making them difficult to spot without direct server access. Troubleshooting SSH Client Connection Hangs at Start provides detailed steps for diagnosing similar initialization failures, which are highly relevant here since the symptoms overlap significantly.

Network and Firewall Interference

Even with correct credentials, network intermediaries can disrupt data flow after the initial handshake. Deep packet inspection appliances or stateful firewalls may allow TCP connections on port 22 but drop subsequent packets if they do not conform to expected SSH patterns. This is particularly common in corporate environments where traffic shaping or security policies are aggressive. If you suspect this, try connecting from a different network segment or using a different port if the server permits alternative SSH ports. Some organizations route SSH through proxies that require additional negotiation, which Plink does not handle natively without explicit proxy configuration. Check for MTU (Maximum Transmission Unit) mismatches as well. While rare in simple terminal sessions, large key exchanges or banner transfers can trigger fragmentation issues if the path MTU is lower than expected. This results in dropped packets that cause the connection to stall. You can test this by reducing the window size or using compression, though these are workarounds rather than fixes. The primary goal is to ensure that the full duplex channel remains open for bidirectional data exchange.

Verifying with Verbose Output

To diagnose the exact point of failure, run Plink with the -v flag for verbose logging. This outputs detailed information about each stage of the connection process, including key exchange, authentication, and channel requests. Pay close attention to the final lines before the hang. If you see messages about channel opening failing, the issue is likely on the server side. If the log stops abruptly without error, the network is likely dropping packets. Comparing the verbose output against known good sessions can reveal subtle differences in request parameters. SSH Connection: Windows 10 Wi-Fi vs. Ethernet highlights how network interface variations can impact stability, suggesting that switching connection types might bypass local routing issues that cause silent drops.

Client-Specific Workarounds

Sometimes the issue resides in how Plink interprets the server’s response. Try specifying the protocol version explicitly using -ssh2 or -ssh1, although SSH1 is deprecated and rarely supported now. Ensure that the terminal type is set correctly using -term, as some servers reject sessions with undefined terminal types. Additionally, check if any global PuTTY registry settings are interfering. Corrupted configuration files in HKEY_CURRENT_USER\Software\SimonTatham\PuTTY can cause unexpected behavior. Resetting to default settings often resolves hidden configuration conflicts. If you are using public key authentication, verify that the key format is compatible. Modern OpenSSH servers may reject older key formats or require specific algorithms. Use plink -v to see which key types are being offered and accepted. If the server prefers Ed25519 or ECDSA and your key is RSA, mismatched preferences can lead to successful authentication but failed channel establishment. Updating your client tools to the latest version ensures support for current cryptographic standards and bug fixes related to session management.

Frequently Asked Questions

Why does Plink say "Access Granted" but then close?

This typically happens when the remote shell or command exits immediately after authentication. Check the user’s profile scripts like .bashrc or .profile for errors that cause early termination. Ensuring these scripts complete successfully will keep the session alive.

Can firewall rules block data after authentication?

Yes, stateful firewalls may inspect payloads and drop packets that do not match expected SSH patterns. This is common in enterprise networks with deep packet inspection. Testing from a different network or adjusting firewall policies for SSH traffic can resolve this.

How do I check if ForceCommand is causing the issue?

Review the sshd_config file on the server for ForceCommand directives associated with the user’s key. Temporarily commenting out these lines allows you to test if standard shell access is restored. Always restart the SSH service after making changes.

Does changing the network adapter affect Plink performance?

Switching between Wi-Fi and Ethernet can reveal if local routing or DNS resolution issues are causing delays. Unstable connections may fail during the key exchange phase, leading to perceived hangs. Using a wired connection often provides more consistent latency for SSH sessions.

What role does the terminal type play in Plink sessions?

The terminal type informs the server about the client’s capabilities for rendering text. Mismatches can cause display corruption or input issues, though rarely total silence. Setting a standard type like xterm via the -term flag often improves compatibility with restrictive servers.