PowerShell / PowerShell/Win32-OpenSSH
Session is closed on ForceCommand internal-sftp
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 8.3k
- Forks
- 819
- PR merge metrics
- No merged PRs in 30d
Description
I'm trying to follow this guide: https://github.com/PowerShell/Win32-OpenSSH/issues/190#issuecomment-585327775 to limit dir access.
Troubleshooting steps
- sshd v8.1.0.0p1-Beta
- Putty v0.74
- Windows 10.0.19041.508 x64 (clear and updated, VMWare)
- sshd_config:
Subsystem sftp internal-sftp -d "C:\temp"
ChrootDirectory C:\temp
#ForceCommand internal-sftp
This works well and automatically open C:\temp dir when the client is connected.
However, I need to restrict access to C:\temp, no parent dirs are allowed.
As soon as I'm adding:
ForceCommand internal-sftp
restarting the sshd service,
after the client is entering password in putty, the window is immediately closed. No session.
Credentials are:
- 127.0.0.1
- User name is a current user from Administrators group.
Logs:
debug1: rexec_argv[0]='sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Server will not fork when running in debugging mode.
Connection from 127.0.0.1 port 63411 on 127.0.0.1 port 22
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
debug1: Remote protocol version 2.0, remote software version PuTTY_Release_0.74
debug1: no match: PuTTY_Release_0.74
debug1: sshd version OpenSSH_for_Windows_8.1, LibreSSL 2.9.2
debug1: get_passwd: LookupAccountName() failed: 1332.
debug1: list_hostkey_types: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: algorithm: curve25519-sha256@libssh.org [preauth]
debug1: kex: host key algorithm: ssh-ed25519 [preauth]
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: rekey out after 4294967296 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 4294967296 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user Alex service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
unable to resolve group administrators
debug1: user alex does not match group list administrators at line 101
debug1: userauth-request for user Alex service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: keyboard-interactive devs [preauth]
debug1: auth2_challenge: user=Alex devs= [preauth]
debug1: kbdint_alloc: devices '' [preauth]
debug1: userauth-request for user Alex service ssh-connection method password [preauth]
debug1: attempt 2 failures 1 [preauth]
Accepted password for Alex from 127.0.0.1 port 63411 ssh2
debug1: monitor_child_preauth: Alex has been authenticated by privileged process
debug1: monitor_read_log: child log fd closed
debug1: Not running as SYSTEM: skipping loading user profile
User child is on pid 6556
debug1: sshd version OpenSSH_for_Windows_8.1, LibreSSL 2.9.2
debug1: get_passwd: LookupAccountName() failed: 1332.
unable to resolve group administrators
debug1: user alex does not match group list administrators at line 101
Changed root directory to "C:\\temp"
debug1: rekey in after 4294967296 blocks
debug1: rekey out after 4294967296 blocks
debug1: ssh_packet_set_postauth: called
debug1: active: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Entering interactive session for SSH2.
debug1: server_init_dispatch
debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug1: server_input_channel_req: channel 0 request pty-req reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req pty-req
debug1: Allocating pty.
debug1: session_pty_req: session 0 alloc windows-pty
debug1: Ignoring unsupported tty mode opcode 3 (0x3)
debug1: Ignoring unsupported tty mode opcode 42 (0x2a)
debug1: server_input_channel_req: channel 0 request shell reply 1
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req shell
Starting session: forced-command (config) 'internal-sftp' on windows-pty for alex from 127.0.0.1 port 63411 id 0
Environment:
USER=alex
LOGNAME=alex
HOME=C:\Users\Alex
PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin
MAIL=/var/spool/mail/alex
SHELL=c:\windows\system32\cmd.exe
TERM=xterm
SSH_CLIENT=127.0.0.1 63411 22
SSH_CONNECTION=127.0.0.1 63411 127.0.0.1 22
SSH_TTY=windows-pty
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 2804
debug1: session_close_by_channel: channel 0: has child, ttyfd 9
debug1: Received SIGCHLD.
debug1: session_by_tty: unknown tty windows-pty
debug1: session_by_pid: pid 2804
debug1: session_exit_message: session 0 channel 0 pid 2804
debug1: session_exit_message: release channel 0
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 child 0
Close session: user alex from 127.0.0.1 port 63411 id 0
debug1: channel 0: free: server-session, nchannels 1
Connection closed by 127.0.0.1 port 63411
debug1: do_cleanup
Transferred: sent 2328, received 1792 bytes
Closing connection to 127.0.0.1 port 63411
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the Windows OpenSSH session with the shown sshd_config, PuTTY, and debug log, comparing behavior with and without ForceCommand internal-sftp. Trace the forced-command session through the available OpenSSH Windows implementation and verify the result with the same configuration; done means the session remains usable or the required configuration limitation is clearly documented.
Written by the indexing model from the issue text.
Assessment
- Domain
- operating-systems, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100