mirror of https://github.com/wolfSSL/wolfssh.git
With -A the echoserver drives its own channels: accept() returns at userauth and the callbacks below start the shell, SFTP or SCP session. Off by default. The two modes are exclusive, since the callbacks answer the session requests the accept state machine otherwise answers itself. - wsShellStartCb() forks the pty, so it is registered in either mode, and claims the channel only once there is a shell behind it; a second request is refused rather than forking over the running shell - wsExecStartCb() takes an "scp " command as a transfer and any other command as a session, and is registered in either mode, since the legacy path has always started a shell for an exec request too - wsSubsysStartCb() is registered only with -A, as accept() serves sftp itself, and guards a NULL command, which a truncated request leaves behind - ssh_worker() drives the session through shellCtx.appFd, claims the channel itself when no callback did, and leaves an SFTP or SCP handoff through its cleanup so the pty master still closes - open the agent channel from the select loop, since the peer's auth-agent-req lands after accept() has returned, and read the listener from the context each pass because it appears mid-loop - resume a subsystem accept that returns a want, waiting on the socket between attempts rather than spinning - close the accepted socket again, clear fwdFd on EOF or reset, and stay in the loop on WS_REKEYING, which the read arm already handles - key ChildRunning's sig_atomic_t on WOLFSSH_SHELL, the only build with the SIGCHLD handler that writes it, so a target whose libc has no signal.h still compiles - ask for echo mode in the keyboard-interactive test, which has no account on the host for the shell callback to fork a shell for |
||
|---|---|---|
| .. | ||
| client | ||
| echoserver | ||
| portfwd | ||
| scpclient | ||
| sftpclient | ||
| tpmcertserver | ||
| include.am | ||