[Ssh] Re: SSHM charter - next steps

[Ron Frederick <[e-mail]>]

Hi Mark,

On Sep 10, 2024, at 10:13 PM, mbaushke ietf <[e-mail]> wrote:
> For AsyncSSH, I believe that the API uses send_env() for passing along environment variables.

For environment settings, AsyncSSH supports both ‘env’ and ’send_env’ arguments, which are the equivalent to OpenSSH’s SetEnv and SendEnv, respectively. The ‘env’ option lets you pass in a dictionary with Unicode string keys & values to send to the server as environment variables, and the ’send_env’ lets you pass a list of Unicode strings which will be looked up in the local environment and forwarded on to the server. In both cases, the Unicode string values are encoded using UTF-8 in the MSG_CHANNEL_REQUEST message, with a request type of ‘env’.

AsyncSSH also supports reading OpenSSH config files, and will fall back to using any SetEnv or SendEnv directives found there if the AsyncSSH ‘env’ and/or ’send_env’ options aren’t passed in. The data in the config file is expected to be encoded as UTF-8, if any non-ASCII bytes are present in it. Parsing failures will occur if the data is not valid UTF-8.

AsyncSSH can also be used as a server, but it is designed to let the application using it handle all the I/O on the sessions, rather than forking off a process to run a shell or execute a command. As a result, it doesn’t have a concept of ‘AcceptEnv’. It just passes the application the complete set of environment variables sent by the client and lets the application decide what it wants to do with these key/value pairs, if anything. As above, the data in the MSG_CHANNEL_REQUEST is decoded using UTF-8 and passed to the application as Unicode strings. Requests with invalid UTF-8 keys or values are ignored (with an optional debug-level log message).

For usernames and passwords, AsyncSSH applies SASLprep (RFC 4013) on the Unicode version of the value and then encodes the normalized result as UTF-8, as recommended by RFC 4252.

In other places, AsyncSSH will let the application specify an encoding explicitly, such as when reading and writing data on a channel. It also supports the ability to set the encoding to ’None’, which makes it accept and return raw bytes instead of Unicode strings, allowing arbitrary binary data to be sent and received.

I’d be curious about any encoding-related problems that people have run across, and would also be interested in interoperability testing with other SSH implementations if anyone is interested. I do some of my own testing against OpenSSH, and have also done limited testing against other implementations. So far, I haven’t run across any issues related to Unicode encoding.
-- 
Ron Frederick
[e-mail]