This document describes the multiplexing protocol used by ssh(1)'s ControlMaster connection-sharing. Most messages from the client to the server contain a "request id" field. This field is returned in replies as "client request id" to facilitate matching of responses to requests. 1. Connection setup When a multiplexing connection is made to a ssh(1) operating as a ControlMaster from a ssh(1) in multiplex slave mode, the first action of each is to exchange hello messages: uint32 MUX_MSG_HELLO uint32 protocol version string extension name [optional] string extension value [optional] ... The current version of the mux protocol is 4. A slave should refuse to connect to a master that speaks an unsupported protocol version. Following the version identifier are zero or more extensions represented as a name/value pair. No extensions are currently defined. 2. Opening sessions To open a new multiplexed session, a client may send the following request: uint32 MUX_C_NEW_SESSION uint32 request id string reserved bool want tty flag bool want X11 forwarding flag bool want agent flag bool subsystem flag uint32 escape char string terminal type string command string environment string 0 [optional] ... To disable the use of an escape character, "escape char" may be set to 0xffffffff. "terminal type" is generally set to the value of $TERM. zero or more environment strings may follow the command. The client then sends its standard input, output and error file descriptors (in that order) using Unix domain socket control messages. The contents of "reserved" are currently ignored. If successful, the server will reply with MUX_S_SESSION_OPENED uint32 MUX_S_SESSION_OPENED uint32 client request id uint32 session id Otherwise it will reply with an error: MUX_S_PERMISSION_DENIED or MUX_S_FAILURE. Once the server has received the fds, it will respond with MUX_S_OK indicating that the session is up. The client now waits for the session to end. When it does, the server will send an exit status message: uint32 MUX_S_EXIT_MESSAGE uint32 session id uint32 exit value The client should exit with this value to mimic the behaviour of a non-multiplexed ssh(1) connection. Two additional cases that the client must cope with are it receiving a signal itself and the server disconnecting without sending an exit message. A master may also send a MUX_S_TTY_ALLOC_FAIL before MUX_S_EXIT_MESSAGE if remote TTY allocation was unsuccessful. The client may use this to return its local tty to "cooked" mode. uint32 MUX_S_TTY_ALLOC_FAIL uint32 session id 3. Health checks The client may request a health check/PID report from a server: uint32 MUX_C_ALIVE_CHECK uint32 request id The server replies with: uint32 MUX_S_ALIVE uint32 client request id uint32 server pid 4. Remotely terminating a master A client may request that a master terminate immediately: uint32 MUX_C_TERMINATE uint32 request id The server will reply with one of MUX_S_OK or MUX_S_PERMISSION_DENIED. 5. Requesting establishment of port forwards A client may request the master to establish a port forward: uint32 MUX_C_OPEN_FWD uint32 request id uint32 forwarding type string listen host string listen port string connect host string connect port forwarding type may be MUX_FWD_LOCAL, MUX_FWD_REMOTE, MUX_FWD_DYNAMIC. A server may reply with a MUX_S_OK, a MUX_S_REMOTE_PORT, a MUX_S_PERMISSION_DENIED or a MUX_S_FAILURE. For dynamically allocated listen port the server replies with uint32 MUX_S_REMOTE_PORT uint32 client request id uint32 allocated remote listen port 6. Requesting closure of port forwards Note: currently unimplemented (server will always reply with MUX_S_FAILURE). A client may request the master to close a port forward: uint32 MUX_C_CLOSE_FWD uint32 request id string listen host string listen port string connect host string connect port A server may reply with a MUX_S_OK, a MUX_S_PERMISSION_DENIED or a MUX_S_FAILURE. 7. Requesting stdio forwarding A client may request the master to establish a stdio forwarding: uint32 MUX_C_NEW_STDIO_FWD uint32 request id string reserved string connect host string connect port The client then sends its standard input and output file descriptors (in that order) using Unix domain socket control messages. The contents of "reserved" are currently ignored. A server may reply with a MUX_S_SESSION_OPENED, a MUX_S_PERMISSION_DENIED or a MUX_S_FAILURE. 8. Requesting shutdown of mux listener A client may request the master to stop accepting new multiplexing requests and remove its listener socket. uint32 MUX_C_STOP_LISTENING uint32 request id A server may reply with a MUX_S_OK, a MUX_S_PERMISSION_DENIED or a MUX_S_FAILURE. 9. Status messages The MUX_S_OK message is empty: uint32 MUX_S_OK uint32 client request id The MUX_S_PERMISSION_DENIED and MUX_S_FAILURE include a reason: uint32 MUX_S_PERMISSION_DENIED uint32 client request id string reason uint32 MUX_S_FAILURE uint32 client request id string reason 10. Protocol numbers #define MUX_MSG_HELLO 0x00000001 #define MUX_C_NEW_SESSION 0x10000002 #define MUX_C_ALIVE_CHECK 0x10000004 #define MUX_C_TERMINATE 0x10000005 #define MUX_C_OPEN_FWD 0x10000006 #define MUX_C_CLOSE_FWD 0x10000007 #define MUX_C_NEW_STDIO_FWD 0x10000008 #define MUX_C_STOP_LISTENING 0x10000009 #define MUX_S_OK 0x80000001 #define MUX_S_PERMISSION_DENIED 0x80000002 #define MUX_S_FAILURE 0x80000003 #define MUX_S_EXIT_MESSAGE 0x80000004 #define MUX_S_ALIVE 0x80000005 #define MUX_S_SESSION_OPENED 0x80000006 #define MUX_S_REMOTE_PORT 0x80000007 #define MUX_S_TTY_ALLOC_FAIL 0x80000008 #define MUX_FWD_LOCAL 1 #define MUX_FWD_REMOTE 2 #define MUX_FWD_DYNAMIC 3 XXX TODO XXX extended status (e.g. report open channels / forwards) XXX lock (maybe) XXX watch in/out traffic (pre/post crypto) XXX inject packet (what about replies) XXX server->client error/warning notifications XXX send signals via mux $OpenBSD: PROTOCOL.mux,v 1.7 2011/05/08 12:52:01 djm Exp $