ssh1, sshnet, scp, sshserve – encrypted login and file copy with
foreign systems via SSHv1|
ssh1 [ –CfiImPpRrw ] [ –A authlist ] [ –c cipherlist ] [ –[lu] user
] [user@]host [ cmd [ args ... ]] |
sshnet [ –A authlist ] [ –c cipherlist ] [ –m mtpt ] [ –s service ] [user@]host
scp [host:]file [host2:]file2
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 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:
–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.
. Return from the escape.
!cmdRun 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 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 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 option above).
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 enable TIS_Authentication.
When the connection is authenticated, the given command line,
(by default, a login shell) is executed on the remote host.
Server and Keys
Sshserve requires that factotum(4) hold the host key, identified
by having attributes proto=rsa service=sshserve. To generate a
con(1), cpu(1), ssh2(1), factotum(4), authsrv(6), rsa(8)