SSH1(1) SSH1(1)
NAME
ssh1, sshnet, scp1, sshserve - secure login and file copy
from/to Unix or Plan 9
SYNOPSIS
ssh1 [ -CfiImPpRrw ] [ -A authlist ] [ -c cipherlist ] [
-[lu] user ] [user@]host [ cmd [ args ... ]]
sshnet [ -A authlist ] [ -c cipherlist ] [ -m mtpt ] [ -s
service ] [user@]host
scp1 [host:]file [host:]file
scp1 [host:]file ... [host:]dir
aux/sshserve [ -p ] address
DESCRIPTION
Ssh1 allows authenticated login over an encrypted channel to
hosts that support the ssh protocol (see the RFCs listed
below for encryption and authentication details).
Ssh1 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.
-f enable agent forwarding. With this flag, ssh1 uses
SSH's agent forwarding protocol to allow programs run-
ning on the remote server to interact with factotum(4)
to perform RSA authentication.
-i force interactive mode. In interactive mode, ssh1
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, ssh1 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 ssh1 protocol,
grounded in Unix tradition, differentiates between
Page 1 Plan 9 (printed 11/18/24)
SSH1(1) SSH1(1)
connections that request controlling pseudoterminals
and those that do not. By default, ssh1 requests a
pseudoterminal only when no command is given.
-P force no pseudoterminal request.
-r strip carriage returns.
-R put the allocated pseudoterminal, if any, in raw mode.
-w notify the remote side whenever the window changes
size.
-[lu] user
specify user name. This option is deprecated in favor
of the user@hostname syntax.
-A authlist
specify an ordered space-separated list of authentica-
tion protocols to try. The full set of authentication
protocols is rsa (RSA using factotum(4) to moderate key
usage), password (use a password gathered from facto-
tum), and tis (challenge-response). The default list
is all three in that order.
-c cipherlist
specify an ordered space-separated list of allowed
ciphers to use when encrypting the channel. The full
set of ciphers is des (standard DES), 3des (a somewhat
doubtful variation on triple DES), blowfish (Bruce
Schneier's Blowfish), rc4 (RC4), and none (no encryp-
tion). The default cipher list is blowfish rc4 3des.
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.
Ssh1 establishes a connection with an ssh daemon on the
remote host. The daemon sends to ssh1 its RSA public host
Page 2 Plan 9 (printed 11/18/24)
SSH1(1) SSH1(1)
key and session key. Using these, ssh1 sends a session key
which, presumably, only the daemon can decipher. After
this, both sides start encrypting their data with this ses-
sion key.
When the daemon's host key has been received, ssh1 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, ssh1 is
satisfied. If not, ssh1 reports this and offers to add the
key to $home/lib/keyring.
Over the encrypted channel, ssh1 attempts to convince the
daemon to accept the call using the listed authentication
protocols (see the -A option above).
The preferred way to authenticate is a netkey-style
challenge/response or via a SecurID token. Ssh1 users on
other systems than Plan 9 should enable TIS_Authentication.
When the connection is authenticated, the given command
line, (by default, a login shell) is executed on the remote
host.
The SSH protocol allows clients to make outgoing TCP calls
via the server. Sshnet establishes an SSH connection and,
rather than execute a remote command, presents the remote
server's TCP stack as a network stack (see the discussion of
TCP in ip(3)) mounted at mtpt (default /net), optionally
posting a 9P service descriptor for the new file system as
/srv/service. The -A and -c arguments are as in ssh1.
Scp1 uses ssh1 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). Scp1 can copy files from remote hosts and
to remote hosts.
Sshserve is the server that services ssh1 calls from remote
hosts. The -A and -c options set valid authentication meth-
ods and ciphers as in ssh1, except that there is no rsa
authentication method. Unlike in ssh1, the list is not
ordered: the server presents a set and the client makes the
choice. The default sets are tis and blowfish rc4 3des. 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.
Sshserve does not provide the TCP forwarding functionality
used by sshnet, because many Unix clients present this capa-
bility in an insecure manner.
Sshserve requires that factotum(4) hold the host key, iden-
tified by having attributes proto=rsa service=sshserve. To
generate a host key:
Page 3 Plan 9 (printed 11/18/24)
SSH1(1) SSH1(1)
auth/rsagen -t 'service=sshserve' >/mnt/factotum/ctl
To extract the public part of the host key in the form used
by SSH key rings:
grep 'service=sshserve' /mnt/factotum/ctl | auth/rsa2ssh
FILES
/sys/lib/ssh/keyring
System key ring file containing public keys for remote
ssh clients and servers.
/usr/user/lib/keyring
Personal key ring file containing public keys for
remote ssh clients and servers.
SOURCE
/sys/src/cmd/ssh
SEE ALSO
/lib/rfc/rfc425[0-6]
factotum(4), authsrv(6), rsa(8)
BUGS
Only version 1 of the SSH protocol is implemented.
Page 4 Plan 9 (printed 11/18/24)