CLI Frontend

General

CLI is the default frontend if you requesting a reglar shell session without command; you can also use command cli in SSH exec request to request this frontend.
If a pseudoterminal is requested and available, readline library will be used in this frontend to enable user friendly line editing and auto-completing features; since version 1.2, readline support can also be forcibly enabled even without a PTY, by passing an environment variable, see chapter Other useful environment variables for details.

CLI commands

Input lines that start with a slash / are interpreted as commands. Following commands are supported as of version 1.1:

Command	Description
who	print currently on-line users
list	alias of who
alert	whether to run the terminal bell on every message
bell	alias of alert
showhtml	whetcher to print HTML messages
msg	send a private message to specified user
tell	alias of msg
motd	print the message of the day from server if available
pasteimage	send an image via X11 forwarding to specified user, X11 forwarding must be available in both SSH client and server
listoptions	list all CLI options and current values
version	print version and copyright information of the server side programs
quit	quit current session
help	print brief usage lines of all commands

Cannot input Unicode text?

In some configurations, CLI frontend cannot accept Unicode characters input. This is due to the readline library don't recognize Unicode characters if it isn't told to do, by environment variable LANG or LC_CTYPE. if SSH client does not sent a vaild environment variable that set the encoding to server side, or the SSH server doesn't accept the variables from client, readline will handle only ASCII inputs. A vaild LANG or LC_CTYPE variable should have two part like en_US.UTF-8. The en_US indicate your language settings, and UTF-8 indicating your text encoding. Readline need to know your text encoding to enable Unicode input support.
If both LANG and LC_CTYPE are set, LC_CTYPE will take effect for text encoding; unicode handing in readline won't work if LC_CTYPE has a invalid format even LANG is correctly set. Note that setting LANG will also affecting the UI language.

To test whether this issue is at server side, use this command line:

 LANG=en_US.UTF-8 ssh sshout@example.com -o SendEnv=LANG

If the issue gone, meaning the server side configuration is fine, and you need to configure your shell and/or SSH client.
Putting option SendEnv LANG into ssh_config(5) is recommended, so you won't need to use -o SendEnv=LANG everytime with ssh(1). ssh_config(5) is usually loacted at /etc/ssh/ssh_config and ~/.ssh/config; check the man page in your OS for details. You can use LC_CTYPE instead if you prefer that.
See later chapter Passing custom environment variables from command line with SSH client for more information on passing environment variables from command line.

Of course when setup a server, you should configure your SSH server to accept the LANG and/or LC_CTYPE variable that sent by client. Make sure something like AcceptEnv LANG exists in your sshd_config(5) (usually at /etc/ssh/sshd_config).

SSH client on Cygwin have a special case here. If your locale using CJK characters, your LANG variable may be something like zh_CN.UTF-8@cjknarrow. Please remove @cjknarrow from your LANG variable before connecting, as readline library may not recognize this modifier.

Other useful environment variables

In addition to LANG and LC_CTYPE variables describe above, there are some other varables that could control the behavior of the CLI frontend.

Again the SSH server must be configured to accept those environment variables so they could be passed to sshoutd if available. For example in sshd_config(5):

Match User sshout
    AcceptEnv TZ RL_*

Note this time AcceptEnv was limited to the sshout user only, as a recommendation, because it may be considered insecure to accept all of those environment variables globally.

TZ

This variable can change the timezone for message timestamps, as well as the timezone for controlling the day-change notify message.
See tzset(3) for formats.

For security reason only timezone offset or a relative path containing no '..' directory name, are accepted.

RL_EDITING_MODE

This variable change the editing mode of Readline, if Readline is going to be used.
Acceptable values are emacs for EMACS-like key-binding, and vi for Vi-like key-binding.
The default setting are platform-depended, but it is usually emacs.

Available since version 1.2.

RL_FORCE_ENABLE

Normally the Readline is not used if PTY isn't requested by SSH client (implemented by detecting whether a client mode sshoutd has a terminal as its stdin, this is a technical detail), but if this variable is defined to anything other than empty string, Readline support will be forcibly enabled.

This could be useful if you need to pipe the output from this frontend to another program, but the SSH client redirected stderr to stdout when PTY is enabled, leading your own input echos being piped as well.

If you are going to enable Readline support in a terminal without requesting PTY to SSH server (for example, by passing option -T to ssh(1)), you may need to reconfigure your local terminal to disable input line buffering and local echoing; this could be done by using stty(1) command, like:

stty -icanon -echo

To revert the changes after you left chat, run:

stty icanon echo

Available since version 1.2.

Passing custom environment variables from command line with SSH client

Different SSH clients may have very different ways to pass environment variables to a server, following examples applying for OpenSSH ssh(1) command only.

If you have OpenSSH version 7.7 or later, there is a SetEnv option available for passing enviroment variables directly from ssh(1) command line, for example:

ssh -o "SetEnv LANG=en_GB.UTF-8 TZ=UTC RL_EDITING_MODE=vi" ...

otherwise define the environment variables for ssh(1) and use SendEnv to allow them to be passed:

LANG=en_GB.UTF-8 TZ=UTC RL_EDITING_MODE=vi ssh -o "SendEnv LANG TZ RL_EDITING_MODE" ...