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, password 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 connections that request controlling pseudoterminals and those that do not. By default, ssh requests a pseudoterminal only when no command is given.

-r strip carriage returns.

-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 session 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 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 protected by encryption as it travels from the remote host to sshserve. The -p option keeps sshserve from accepting passwords, 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 readable 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 containing public keys for remote ssh clients and servers.

/mnt/auth/ssh Expected mount point for private keys held by an agent.

/usr/user/lib/userkeyring
Personal keyring file containing private keys to be used in authentication.

SOURCE

/sys/src/cmd/ssh

Museum