SSH(1) SSH(1)
NAME
ssh, sshserve, scp - secure login and file copy from/to Unix
or Plan 9
SYNOPSIS
ssh [ -CiImprv ] [ -[lu] user ] [user@]hostname [ command [
arguments ... ]]
scp [host:]file [host:]file
scp [host:]file ... [host:]dir
sshserve [ -p ] address
aux/ssh_genkey [ -d ] [ basename ]
DESCRIPTION
Ssh allows authenticated login over an encrypted channel to
hosts that support the ssh protocol (see the RFC listed
below for encryption and authentication details).
Ssh takes the host name of the machine to connect to as its
mandatory argument. It may be specified as a domain name or
an IP address. Normally, login is attempted using the user
name from /dev/user.
Command-line options are:
-C force input to be read in cooked mode: ``line at a
time'' with local echo.
-i force interactive mode. In interactive mode, ssh
prompts for passwords and confirmations of new host
keys when necessary. (In non-interactive mode, pass-
word requests are rejected and unrecognized host keys
are cause for disconnecting.) By default, ssh runs in
interactive mode only when its input file descriptor is
/dev/cons.
-I force non-interactive mode.
-m disable the control-\ menu, described below.
-p force pseudoterminal request. The ssh protocol,
grounded in Unix tradition, differentiates between con-
nections that request controlling pseudoterminals and
those that do not. By default, ssh requests a pseu-
doterminal only when no command is given.
-r strip carriage returns.
Page 1 Plan 9 (printed 4/19/24)
SSH(1) SSH(1)
-v enable verbose feedback during the connection and
authentication process.
-[lu] user
specify user name. This option is deprecated in favor
of the user@hostname syntax.
The control-\ character is a local escape, as in con(1). It
prompts with >>>. Legitimate responses to the prompt are
q Exit.
. Return from the escape.
!cmd Run the command with the network connection as its
standard input and standard output. Standard error
will go to the screen.
r Toggle printing of carriage returns.
If no command is specified, a login session is started on
the remote host. Otherwise, the command is executed with
its arguments.
Ssh establishes a connection with an ssh daemon on the
remote host. The daemon sends to ssh its RSA public host
key and session key. Using these, ssh sends a session key
which, presumably, only the daemon can decipher. After
this, both sides start encrypting their data with this ses-
sion key. The encryption algorithm preferred by Plan9 ssh
for data transfer is RC4, with triple-DES (which isn't
really triple DES but a somewhat doubtful variation on it)
as backup. (All ssh implementations are required to be able
to do 3DES.)
When the daemon's host key has been received, ssh looks it
up in $home/lib/keyring and in /sys/lib/ssh/keyring. If the
key is found there, and it matches the received key, ssh is
satisfied. If not, ssh reports this and offers to add the
key to $home/lib/keyring.
Over the encrypted channel, ssh attempts to convince the
daemon to accept the call. It will try to use RSA private
keys, first those mounted at /mnt/auth/ssh (see agent(4)),
and then any in the private keyring $home/lib/userkeyring.
If RSA authentication fails, ssh may prompt for the password
on the remote host - note that this password will be sent
over the encrypted channel. This is safe, provided one is
indeed connected to the intended host.
The preferred way to authenticate the user, however, is the
Page 2 Plan 9 (printed 4/19/24)
SSH(1) SSH(1)
challenge/response system used by netkey. Ssh users on other
systems than Plan 9 should enable TIS_Authentication.
When the connection is established, the command given in the
remaining arguments, or the shell, is started up on the
remote host.
Scp uses ssh to copy files from one host to another. A
remote file is identified by a host name, a colon and a file
name (no spaces). Scp can copy files from remote hosts and
to remote hosts.
Sshserve is the server that services ssh calls from remote
hosts. On Plan 9, it always requires either a response to a
challenge (netkey), or a password. The password is pro-
tected by encryption as it travels from the remote host to
sshserve. The -p option keeps sshserve from accepting pass-
words, forcing the use of the netkey-style challenge-
response. By default, users start with the namespace
defined in /lib/namespace. Users in group noworld in
/adm/users start with the namespace defined in
/lib/namespace.noworld.
Ssh_genkey generates an RSA key set, writing the private key
to basename.secret and the public key to basename.public.
The default basename is /sys/lib/ssh/hostkey, so running it
with no arguments will generate an RSA key set for the file
server in use. Unlike the ssh used by Unix machines, the
Plan 9 ssh stores its keys in hexadecimal. Invoking
ssh_genkey with the -d option causes it to create a decimal
public key in basename.public10, useful for sharing with
Unix hosts.
FILES
/sys/lib/ssh/hostkey.public Public key for the host on
which the program runs.
/sys/lib/ssh/hostkey.secret Secret key for the host on
which the program runs. This
file must be owned and be read-
able by bootes only.
/sys/lib/ssh/keyring System keyring file containing
public keys for remote ssh
clients and servers.
/usr/user/lib/keyring Personal keyring file contain-
ing public keys for remote ssh
clients and servers.
/mnt/auth/ssh Expected mount point for pri-
vate keys held by an agent.
/usr/user/lib/userkeyring Personal keyring file contain-
ing private keys to be used in
authentication.
Page 3 Plan 9 (printed 4/19/24)
SSH(1) SSH(1)
SOURCE
/sys/src/cmd/ssh
SEE ALSO
/sys/src/cmd/ssh/RFC*
agent(4), auth(6)
Page 4 Plan 9 (printed 4/19/24)