NAME

	cpu – secure connection to CPU server

SYNOPSIS

	cpu [ –h server ] [ –u user ] [ –tv ] [ –a auth–method ] [ –P patternfile ] [ –e encryption–hash–algs ] [ –k keypattern ] [ –c cmd args ... ] cpu [ –C cert ] [ –t ] –R

DESCRIPTION

Cpu starts an rc(1) running on the server machine, or the machine named in the $cpu environment variable if there is no –h option. Rc's standard input, output, and error files will be /dev/cons in the name space where the cpu command was invoked. Normally, cpu is run in an rio(1) window on a terminal, so rc output goes to that window, and input comes from the keyboard when that window is current. Rc's current directory is the working directory of the cpu command itself. The name space for the new rc is an analogue of the name space where the cpu command was invoked: it is the same except for architecture–dependent bindings such as /bin and the use of fast paths to file servers, if available. If a –u argument is present, cpu uses the argument as the remote user id. If a –c argument is present, the remainder of the command line is executed by rc on the server, and then cpu exits. If a –P argument is present, the patternfile is passed to exportfs(4) to control how much of the local name space will be exported to the remote system. The –a option allows the user to specify the authentication mechanism used when connecting to the remote system. The two possibilities for auth–method are: p9       This is the default. Authentication is done using the standard Plan 9 mechanisms, (see authsrv(6)). No user interaction is required. netkey   Authentication is done using challenge/response and a hand held authenticator or the netkey program (see passwd(1)). The user must encrypt the challenge and type the encryption back to cpu. This is used if the local host is in a different protection domain than the server or if the user wants to log into the server as a different user. The connection will be encrypted. Cpu will attempt to establish a TLS connection first, to service cpu–tls. TLS will negotiate encryption algorithms common to client and server. If a TLS connection fails, and in the absence of –t, cpu will attempt a less–secure SSLv2 connection to service ncpu. The –e option specifies an encryption and/or hash algorithm to use for any SSLv2 connection. If both are specified, they must be space separated and comprise a single argument, so they must be quoted if in a shell command. The default is rc4_256 encryption and sha1 hashing. See ssl(3) for details on possible (weak) algorithms. The argument clear specifies no SSLv2 encryption, primarily for debugging. The –v option prints connection attempts, identifying the protocol used. The –k option specifies a key pattern to use to restrict the keys selected by the auth_proxy call used for authentication. The name space is built by running /usr/$user/lib/profile with the root of the invoking name space bound to /mnt/term. The service environment variable is set to cpu; the cputype and objtype environment variables reflect the server's architecture. The –R option causes cpu to run the server (remote) side of the protocol, and must be the final option. It is run from service files such as /bin/service/tcp1701[04]. With –t, cpu will expect a TLS connection; without it, cpu will expect an SSLv2 connection. –C names an alternate pem(8)–encoded cert for TLS, and implies –t.

FILES

	/sys/lib/ssl/cert.pem       default certificate The name space of the terminal side of the cpu command is mounted, via exportfs(4), on the CPU side on directory /mnt/term. The files such as /dev/cons are bound to their standard locations from there.

SOURCE

	/sys/src/cmd/cpu.c

SEE ALSO

	rc(1), rio(1), tls(3), exportfs(4), drawterm(8)

BUGS

	Binds and mounts done after the terminal lib/profile is run are not reflected in the new name space. When using the –a option to `log in' as another user, be aware that resources in the local name space will be made available to that user. SSLv2 is deprecated.

Copyright © 2024 Plan 9 Foundation. All rights reserved.