ssh, sshsession, sshtun, scp, rsa2ssh2 – Plan 9 support for SSHv2|
ssh [ –CdriIvaxkKm ] [ –l user ] [ –n dir ] [ –s subsystem ] [ –z attribute=value
] addr [ cmd [ args ]]
scp [host:]file ... [host:]dir
These programs collectively provide support for SSHv2 for Plan
9. It supports only SSHv2 and will reject connections with a remote
system that supports only SSHv1. Both client and server operation
is provided. All of the encryption, authentication, and SSH protocol
are handled by a tunnel that is presented as a
protocol directory in /net.|
Ssh and scp are the applications that provide normal client access
to the SSH tunnel. Ssh dials a remote system and runs a shell
(or some other command) there. In its simplest usage, it works
like any other ssh command line application. So the command:|
–C Cooked mode, echo characters typed locally, this is useful on high latency links and allows the use of all of rio(1)'s editing facilities.
–d Increase the amount of debugging output.
–l A deprecated method of specifying the user name on the remote system.
–r Strip carriage return characters coming from the remote system. This will normally be desired when running in a raw rio(1) window or from within win in acme(1). It is normally not used when running ssh from within vt(1).
–k Skip the attempt to authenticate using public key authentication.
–K Do not fall back to password authentication. If the public key authentication fails, ssh will exit.
–m Remove the special meaning of control–\. This is needed by scp to prevent that character in files being copied from triggering the special command mode.
–n Specify the network directory of an alternate network to use. The default is /net.
–s Request an ssh2 subsystem on the remote server, this is used by sftpfs(4).
–z Used to specify which of several possible keys to use.
The sshsession program provides the server functionality for SSHv2.
It is suitable for running by listen(8) Therefore, it is not normally
run directly by the user. Like ssh, it does all of its communication
through the tunnel. Sshsession handles running a shell or a requested
command when a remote system requests a new
connection and session.
–s Specify an alternative to /bin/rc for shell sessions.
–r Specify a starting directory for the ssh session to run in.
–R Same as –r but additionally prevent any arguments on the command line to be executed from referencing anything outside this directory. This is mostly used to limit where scp can deposit or get files.
–n Specify a namespace(6) file to be used before starting the shell or running the requested command. The default is /lib/namespace.
–S Specify an alternative file in /srv where the tunnel can be found if it is not already mounted in /net.
–t Specify that the sshsession instance is trusted and should run in the same name space as the listen that started it.
Sshtun is the program that implements the ssh tunnel used by ssh
and sshsession. It handles all the necessary work to implement
SSHv2. The following options may be given to sshtun|
–d Increase the amount of debugging output.
–k Use keyfs(4) for password validation.
–m Mount point for the ssh protocol directory; defaults to /net.
–s Name to post in /srv. If –s is not given, no file is posted to /srv.
During the initial connection exchange, both parties send lists
of supported algorithms. The first algorithms listed are for key
exchange. This implementation supports the diffie–hellman–group1–sha1
and diffie–hellman–group14–sha1 key exchange algorithms. The second
list is the set of
algorithms for which corresponding host keys exist. Both the ssh–rsa
and ssh–dss algorithms are supported. The next lists are encryption
algorithms, which may be negotiated independently for the server–to–client
and client–to–server directions. This implementation supports the
aes192–cbc, aes256–cbc, 3des–cbc, and arcfour algorithms with preference
given in that order. Finally, the message authentication code
algorithms are listed, and only the hmac–sha1 algorithm is supported
There are a number of different keys that are used by the SSH
tunnel. Most of them are expected to be stored in the instance
of factotum(4) running in the name space of that tunnel instance.
However, in some cases, there are alternative locations available.
1. The selected key must have both proto=rsa and !dk= attributes present.
2. Among those keys, the attributes user=, sys=, and the attribute/value pair specified in the –z option to ssh, if any, are examined. The value of the user attribute is expected to be the user name being authenticated on the remote system, and the value of the sys attribute is expected to be the remote
RFCs 4250, 4251, 4252, 4253, 4254, and 4419, secstore(1), vt(1),
factotum(4), keyfs(4), authsrv(6), listen(8), rsa(8), sftpfs(4)|
TCP/IP forwarding and some potentially useful channel requests
have not been implemented. Zlib compression is not supported,
also probably not needed. Several aspects of key management still
need some work.|