PSFTP Connection Automatically Closing: Keypress Issue

PSFTP connections closing upon keypress usually stem from the SSH client interpreting standard input as an interactive shell command rather than SFTP protocol data. This occurs when the server assigns a login shell to the user instead of the SFTP subsystem, causing the terminal to process keystrokes immediately after authentication. Disabling shell access or forcing the SFTP subsystem resolves this behavior by ensuring the connection remains dedicated to file transfer operations.

Understanding the Root Cause

The Secure File Transfer Protocol (SFTP) operates over an SSH connection. When you initiate a session with psftp, the SSH daemon on the remote server must decide how to handle the authenticated user. By default, many Linux distributions configure the user account to have a valid login shell, such as /bin/bash or /bin/sh. When PSFTP connects, it requests the sftp subsystem. However, if the server configuration or user profile forces an interactive shell session, the terminal becomes active. In this state, any keystroke you press is sent directly to the shell for interpretation. The SFTP client, expecting binary protocol responses, receives unexpected character data and may disconnect or behave erratically because the stream is no longer purely SFTP traffic. This is distinct from network timeouts or permission errors; it is a fundamental mismatch between the client's expectation of a file-transfer-only channel and the server's provision of an interactive terminal.

Verifying the Shell Assignment

To confirm if this is the issue, check the user's entry in the /etc/passwd file on the server. If the last field is set to a valid shell path rather than /sbin/nologin or /usr/sbin/nologin, the user is permitted to log in interactively. While some workflows require shell access for administrative tasks, using the same account for automated or script-based SFTP transfers via PSFTP can lead to these closure issues. For environments requiring multiple file sources, proper directory setup is crucial to maintain security boundaries. You can review best practices for managing these directories in our guide on Setting up SFTP Directory for Multiple File Sources on Linux Server.

Solutions for Interactive Closure

There are two primary approaches to resolve this: restricting the user's shell access or configuring PSFTP to ignore interactive prompts. The preferred method for security and stability is to restrict shell access, ensuring the account is used exclusively for file transfers.

Method 1: Restricting User Shell Access

If the user account does not require command-line access, modify the shell path in /etc/passwd to a non-interactive option. This prevents the SSH daemon from launching a shell upon authentication, forcing the connection to remain within the SFTP subsystem. 1. Open the /etc/passwd file with root privileges using a text editor like vi or nano. 2. Locate the line corresponding to the SFTP user. It typically looks like:

username:x:1001:1001::/home/username:/bin/bash

3. Change the final field (/bin/bash) to /usr/sbin/nologin or /sbin/nologin. 4. Save the file and exit. After making this change, the next time the user attempts to connect via SSH or PSFTP, the server will reject interactive shell requests. The SFTP subsystem will still function correctly because it is handled separately by the SSH daemon's internal routing. Note that this change affects all SSH connections for that user, so ensure they do not need shell access for other purposes. If you encounter permission issues after adjusting paths, refer to our troubleshooting guide on SFTP returning permission denied despite correct directory permissions: A tech support guide to verify chroot jail settings.

Method 2: Configuring SSH Daemon for SFTP Only

Alternatively, you can keep the user's shell but force the SSH daemon to use only the SFTP subsystem for specific users. This is achieved through the ForceCommand directive in /etc/ssh/sshd_config. 1. Edit /etc/ssh/sshd_config as root. 2. Add a block for the specific user or group:

Match User sftpuser
    ForceCommand internal-sftp

3. Restart the SSH service to apply changes:

sudo systemctl restart sshd

This configuration ensures that even if the user has a valid shell defined, the SSH daemon overrides it and invokes the internal SFTP server. This method is safer than modifying /etc/passwd directly because it allows for granular control without altering user system accounts.

Alternative Clients and Workarounds

If modifying server configurations is not feasible due to policy restrictions, consider using alternative clients that handle interactive shells more gracefully. Some GUI-based SFTP clients allow you to specify whether to request an interactive shell or stick strictly to file transfer protocols. Additionally, using SSH keys with strict host key checking can help isolate connection issues from authentication problems. For setups requiring enhanced security layers, such as Multi-Factor Authentication, ensure your client supports the required MFA flows to prevent interruptions during the handshake phase. Learn more about securing these transfers with SFTP Requires MFA: How to Upload/Download Files Securely.

Troubleshooting Persistent Issues

If the connection still closes unexpectedly after applying the above fixes, check the SSH server logs (/var/log/auth.log or /var/log/secure). Look for messages indicating "Subsystem request failed" or "Received disconnect." These errors often point to configuration mismatches in sshd_config, such as incorrect Subsystem sftp paths. Ensure that the path specified matches the actual location of the SFTP server binary on your distribution. Common paths include /usr/lib/openssh/sftp-server or /usr/libexec/openssh/sftp-server. Misconfigurations here can cause immediate disconnection upon subsystem request. For broader connection error diagnostics, consult our article on Troubleshooting SFTP Connection: Subsystem Request Failed.

Frequently Asked Questions

Why does PSFTP work with some servers but not others?

The difference lies in how each server configures the user's default shell. Servers that assign /bin/bash by default will trigger the keypress closure issue, while those configured with /sbin/nologin or forced SFTP commands will not. Always verify the server's PAM and SSH configurations to understand the expected behavior.

Can I use PSFTP if the user needs shell access?

It is generally discouraged to mix interactive shell access with automated SFTP clients like PSFTP. If shell access is required, consider using a different tool like scp or an SFTP client that explicitly handles interactive sessions, such as WinSCP in interactive mode, which manages the terminal state better than command-line PSFTP.

What is the difference between SFTP and FTPS regarding shell access?

SFTP runs over SSH and shares the same authentication mechanism as the shell, meaning shell access controls SFTP availability. FTPS runs over explicit TLS and is typically handled by a separate daemon (like vsftpd) that does not rely on the system's login shell, allowing file transfer without granting shell access.

How do I test if my SSH server is sending a shell instead of SFTP?

Connect to the server using ssh -v username@host and watch the verbose output. If you see "Entering interactive session" followed by shell prompts, the server is providing a shell. If it says "Authenticated" and then immediately offers SFTP commands or stays silent waiting for protocol data, the configuration is correct.

Does disabling shell access affect password changes?

Yes, if the shell is set to /sbin/nologin, users cannot change their passwords via the passwd command unless you configure sudo rules to allow specific commands. Consider using /bin/false if you want to allow specific authorized commands while blocking general shell access, though /usr/sbin/nologin is the standard for SFTP-only accounts.