rad-uri - connecting to RAD by using a URI string
There are multiple ways in which a developer or an administrator can connect to a local or remote RAD instance. These might be specified by using a RAD URI in the RAD client bindings. In addition, some commands such as zoneadm migrate and etrace internally use a RAD connection, and accept RAD URIs as arguments.
RAD connections are encrypted on the wire, and require some form of authentication of the connecting user in order to perform operations on the target.
The current machine's RAD service is enabled by the service FMRI svc:/system/rad:local. The URIs to connect to this service, over a UNIX domain socket, are as follows:
If not specified, username defaults to the current user.
A connection to a remote Oracle Solaris system might be made with URIs of the form:
If not specified, username defaults to the current user. The port parameter is also optional, and defaults to the appropriate port for the defined service. If the scheme is not specified, the default is rads:.
(There is also a rad scheme, which uses an unencrypted connection, so is not recommended or discussed here.)
To connect to a remote system by using the rads: and radg: schemes, the SMF service svc:/system/rad:remote must be enabled on the destination host.
The radg scheme uses GSS-API for authentication, and thus might require a valid Kerberos ticket for the RAD service and the connecting user, which is mapped into a Kerberos user principal.
The rads scheme uses PAM authentication and therefore typically requires the user's login password. Utilities such as zoneadm migrate interactively prompts for the password in these cases.
When connecting to a remote system using TLS, the RAD client will validate that the X.509 certificate presented by the server is issued by a trusted CA, and is issued to that server. The system list of trusted CAs is found in /etc/certs/ca-certificates.crt and is managed by the svc:/system/ca-certificates service.
The certificate presented by the RAD server must also have a correctly formed subject and/or subject AltName with the DNS name set. Certificates generated by the svc:/system/identity:cert service have the required attributes.
Generally certificates are not issued with IP address Subject Alternative Names, so it is unlikely that a rads: URI using IP addresses will work.
Additional issues may occur if the RAD server is behind a NAT gateway or another system that masks the name or address it knows itself by, unless it presents a certificate with the name that the RAD client uses in the connection.
The ssh scheme connects to a remote RAD instance over an SSH tunnel. As a consequence, the SMF service svc:/system/rad:local is the correct service to enable on the destination host.
The SSH connection must be configured such that it does not interactively prompt when connecting to the system. This can be tested by using the following command:
# ssh user@remotehost /bin/true
If you use strict host key checking, ensure that you run this command at least once to store the host identification and prevent further prompts.
Note that some configurations may use different ways of identifying the host (by IP address, by bare hostname, and by FQDN). Ensure that all relevant host identifications are promptless.
If a valid Kerberos ticket is active for the relevant user principal, ssh can use this ticket for authentication and does not require an interactive prompt.
Alternatively, public key authentication can be used between the two systems. As ssh-agent is not supported for RAD connections, a blank passphrase must be used for the keys to avoid a passphrase prompt at connection time. For more information about public key authentication, see the ssh-agent(1) man page.