ssh1, sshnet, scp, sshserve - encrypted login and file copy with for‐
eign systems via SSHv1
SYNOPSISssh1 [ -CfiImPpRrw ] [ -A authlist ] [ -c cipherlist ] [ -[lu] user ]
[user@]host [ cmd [ args ... ]]
sshnet [ -A authlist ] [ -c cipherlist ] [ -m mtpt ] [ -s service ]
scp [host:]file [host2:]file2
scp [host:]file ... [host2:]dir
aux/sshserve [ -A authlist ] [ -c cipherlist ] [ -i id-string ] address
Ssh1 performs authenticated login over an encrypted channel to hosts
that support the SSH v1 protocol (see the RFCs listed below for encryp‐
tion 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
-f enable agent forwarding. With this flag, ssh1 uses SSH's agent
forwarding protocol to allow programs running on the remote
server to interact with factotum(4) to perform RSA authentica‐
-i force interactive mode. In interactive mode, ssh1 prompts for
passwords and confirmations of new host keys when necessary.
(In non-interactive mode, password requests are rejected and
unrecognized host keys are cause for disconnecting.) By
default, ssh 1 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 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.
specify user name. This option is deprecated in favor of the
specify an ordered space-separated list of authentication proto‐
cols to try. The full set of authentication protocols is rsa
(RSA using factotum(4) to moderate key usage), password (use a
password gathered from factotum), and tis (challenge-response).
The default list is all three in that order.
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 encryption). 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
. 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
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 key and session key.
Using these, ssh1 sends a session key which, presumably, only the dae‐
mon can decipher. After this, both sides start encrypting their data
with this session 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
The preferred way to authenticate is a netkey-style challenge/response
or via a SecurID token. SSH users on other systems than Plan 9 should
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 sys‐
tem as /srv/service. The -A and -c arguments are as for ssh1.
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.
Server and Keys
Sshserve is the server that services SSH calls from remote hosts. The
-A and -c options set valid authentication methods and ciphers as for
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. The
-i option prevents reading the client's ID-string line and assumes its
ID string to be id-string. 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 capability in an insecure manner.
Sshserve requires that factotum(4) hold the host key, identified by
having attributes proto=rsa service=sshserve. To generate a host key:
auth/rsagen -t 'service=sshserve' >/mnt/factotum/ctl
To extract the public part of the host key in the form used by SSH key
grep 'service=sshserve' /mnt/factotum/ctl | auth/rsa2ssh
System key ring file containing public keys for remote SSH
clients and servers.
Personal key ring file containing public keys for remote SSH
clients and servers.
con(1), cpu(1), ssh2(1), factotum(4), authsrv(6), rsa(8)SSH1(1)