This file describes the various uses I've made of the DNS extensibility mechanism @rodents.montreal.qc.ca, with some notes on how moussh deals with others' uses of it. [ ] { } in names are to be interpreted as globbing syntax; for example foo[xy]-{one,two} means foox-one, foox-two, fooy-one, fooy-two. arcfour-64k@rodents.montreal.qc.ca (encryption algorithm) This is stock arcfour, but dropping the first 65536 bytes of the keystream. sharc4-512@rodents.montreal.qc.ca (encryption algorithm) This is arcfour, except that keying is modified to generate a more uniform initial permutation. rijndael-k[468]b[468]-{cbc,ctr}@rodents.montreal.qc.ca (encryption algorithm) These are Rijndael in CBC mode (-cbc) or SDCTR mode (-ctr), with key and block sizes as indicated by the numbers: kXbY indicates a key length of X 32-bit units and a block size of Y 32-bit units. (The k*b4 versions are identical to the standard aes* modes; the equivalent names are provided for symmetry.) fixed-auth-agent-req-2@rodents.montreal.qc.ca (channel request) fixed-auth-agent@rodents.montreal.qc.ca (channel type) With standard agent forwarding, there is no way to tell which channel's agent forwarding request a forwarded agent connection is due to. These are equivalent to the standard auth-agent-req channel request and auth-agent channel type except that instead of having no body, they carry bodies. The forwarding request looks like byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "fixed-auth-agent-req-2@rodents.montreal.qc.ca" boolean want reply boolean just-once uint32 cookie and the channel open looks like byte SSH_MSG_CHANNEL_OPEN string "fixed-auth-agent@rodents.montreal.qc.ca" uint32 sender channel uint32 initial window size uint32 maximum packet size uint32 cookie The cookie in the request is an opaque 32-bit value, chosen by the requesting end, which is copied into the cookie value of any resulting channel opens. fixed-auth-agent-req@rodents.montreal.qc.ca (channel request) This is just like fixed-auth-agent-req-2@rodents.montreal.qc.ca except that it has no just-once flag (it operates as if just-once were always false). It exists for compatability with previous versions. In the client, if fixed-auth-agent-req-2@rodents.montreal.qc.ca is rejected, and just-once is false, fixed-auth-agent-req@rodents.montreal.qc.ca is attemped instead, on the theory that we may be talking to an old server. (If that is rejected too, it falls back to stock agent forwarding.) fixed-tcpip-forward@rodents.montreal.qc.ca (channel request) fixed-forwarded-tcpip@rodents.montreal.qc.ca (channel type) With standard TCP connection forwarding, there is no way to tell which channel's connection forwarding request a forwarded connection is due to. These are equivalent to the standard tcpip-forward channel request and forwarded-tcpip channel type except that in each case, the payload is extended by one uint32. This is an opaque cookie, chosen by the requesting end, which is returned with the channel open request so the receiver can tell which forwarding request it is due to. fixed-x11-req-2@rodents.montreal.qc.ca (channel request) fixed-x11@rodents.montreal.qc.ca (channel type) Standard X11 forwarding is rather peculiar. There is no point in passing authentication protocol and cookie information which is faked anyway when the ssh channel provides better security. There also is no way (short of specifying distinctive X authentication info) to tell which forwarding request a given connection comes from. These attempt to fix this. The forwarding request looks like byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "fixed-x11-req-2@rodents.montreal.qc.ca" boolean want reply boolean just-once uint32 cookie uint32 x11 screen number and the channel open looks like byte SSH_MSG_CHANNEL_OPEN string "fixed-x11@rodents.montreal.qc.ca" uint32 sender channel uint32 initial window size uint32 maximum packet size uint32 cookie string connection family ...connection-family-specific data... For TCP connections, "connection family" is "tcp" and the additional data is string remote host uint32 remote port For local connections (/tmp/.X11-unix/*), "connection family" is "local" and there is no additional data. No other "connection family"s have been implemented. The cookie in the channel open is copied from the channel request that established the forwarding. fixed-x11-req@rodents.montreal.qc.ca (channel request) This is just like fixed-x11-req-2@rodents.montreal.qc.ca except that it has no just-once flag (it operates as if just-once were always false). It exists for compatability with previous versions. In the client, if fixed-x11-req-2@rodents.montreal.qc.ca is rejected, and just-once is false, fixed-x11-req@rodents.montreal.qc.ca is attemped instead, on the theory that we may be talking to an old server. (If that is rejected too, it falls back to stock X forwarding.) missing-pty-modes@rodents.montreal.qc.ca (channel request) There are five pieces of terminal state that are not provided for in the pty-req channel request. This request supports them. It will not normally be used on a channel that has not had a pty-req request made on it. It looks like byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "missing-pty-modes@rodents.montreal.qc.ca" boolean want reply ... pairs... The number of pairs present is given by the size of the request packet. Each pair looks like byte opcode byte value where the possible opcodes, their numeric values, and the meanings of their value bytes are ECHOPRT 1 0 or 1 according as ECHOPRT is set ALTWERASE 2 0 or 1 according as ALTWERASE is set NOKERNINFO 3 0 or 1 according as NOKERNINFO is set CS 4 character size in bits (5, 6, 7, or 8) IUTF8 5 0 or 1 according as IUTF8 is set server-debug@rodents.montreal.qc.ca (global request) This allows the client to request debugging information from the server. The request looks like byte SSH_MSG_GLOBAL_REQUEST string "server-debug@rodents.montreal.qc.ca" boolean want reply string argument The "argument" string may have any semantics agreeable between the server and whatever produced the string (usually a human). The mechanism for getting the debugging information back from the server is that the SSH_MSG_REQUEST_SUCCESS packet generated in response looks like byte SSH_MSG_REQUEST_SUCCESS string reply This will not normally be used except when debugging, though peers that implement it must be robust in the face of receiving it at unexpected times, from implementations other than its own, or with malformatted argument strings (whatever "malformatted" means for the implementation in question). client-id@rodents.montreal.qc.ca (agent extension) This agent extension supports clients registering their command-lines with the agent, to allow user interaction with the agent to tell which client is which. Clients do not have to use this; if they choose to, the only defined operation is to set the client command string. The packet for this looks like byte SSH_AGENT_EXTENSION string "client-id@rodents.montreal.qc.ca" string "set" string commandline keepalive@openssh.com (global request) I've been unable to find any real doc on this. Private email indicates that it is the keepalive it looks like, and that sending any response, even a failure, is enough.