The SunSSH implementation of Secure Shell is a fork of the OpenSSH (http://www.openssh.com) project.
Security fixes for vulnerabilities in later versions of OpenSSH have been integrated into the sunssh implementation of Secure Shell (SunSSH), as are individual bug fixes and features.
The following features have been implemented in the current release of SunSSH:
ForceCommand keyword – Forces the execution of the specified command regardless of what the user types on the command line. This keyword is very useful inside a Match block.
AES-128 passphrase protection – Private keys that are generated by the ssh-keygen command are protected with the AES-128 algorithm. This algorithm protects newly generated keys and re-encrypted keys, such as when a passphrase is changed.
–u option to sftp-server command – Enables user to set an explicit umask on files and directories. This option overrides the user's default umask. For an example, see the description of Subsystem on the sshd_config(4) man page.
Additional keywords for Match blocks – AuthorizedKeysFile, ForceCommand, and HostbasedUsesNameFromPacketOnly are supported inside Match blocks. By default, the value of AuthorizedKeysFile is $HOME/.ssh/authorized_keys and HostbasedUsesNameFromPacketOnly is no. To use Match blocks, see How to Create User and Host Exceptions to Secure Shell Defaults.
UseOpenSSLEngine – On x86 systems and on T4-Series and later SPARC systems, this keyword is disabled by default. The platform-specific instructions are already embedded in the OpenSSL cryptographic implementation.
SunSSH differs from OpenSSH in the following ways:
SunSSH-only keywords – SunSSH-only keywords are deprecated in OpenSSH. For a list, see SunSSH Keywords Are Deprecated in OpenSSH.
PAM – SunSSH and OpenSSH always use PAM. Changes to the UsePAM keyword are ignored.
Privilege separation – SunSSH privilege separation code is always on and cannot be switched off. No keyword is associated with privilege separation. The SunSSH implementation separates the processing of auditing, record keeping and re-keying from the processing of the session protocols.
On OpenSSH, configure the UsePrivilegeSeparation keyword.
Locale – SunSSH fully supports language negotiation as specified in Secure Shell Transfer Protocol, RFC 4253. After the user logs in, the user's login shell profile can override the Secure Shell negotiated locale settings.
OpenSSH does not support language negotiation.
Auditing – SunSSH is fully integrated into the Oracle Solaris audit service. For information about the audit service, see Managing Auditing in Oracle Solaris 11.3.
Like OpenSSH, SunSSH is a consumer of the OpenSSL FIPS 140-2 module. Unlike OpenSSH, SunSSH must be configured to link to the OpenSSL FIPS 140-2 module. To comply with FIPS 140-2 requirements, administrators should configure and use the FIPS 140-2 options for SunSSH.
SunSSH in FIPS 140-2 mode is not the default. As the administrator, you must explicitly enable SunSSH to run in FIPS 140-2 mode with the following command:
$ ssh -o "UseFIPS140 yes" remote-host
You can also set a keyword in the configuration files.
Briefly, the implementation consists of the following:
The following FIPS 140-2 approved ciphers are available on the SunSSH server and client side: aes128-cbc, aes192-cbc, and aes256-cbc.
3des-cbc is available by default on the client side, but it is not in the SunSSH server-side cipher list because of potential security risks.
The following FIPS 140-2 approved Message Authentication Codes (MAC) are available:
hmac-sha1, hmac-sha1-96
hmac-sha2-256, hmac-sha2-256-96
hmac-sha2-512, hmac-sha2-512-96
Four SunSSH server-client configurations are supported:
No FIPS 140-2 mode on either the client or the server
FIPS 140-2 mode on both the client and the server
FIPS 140-2 mode on the server but no FIPS 140-2 mode on the client
No FIPS 140-2 mode on the server but FIPS 140-2 mode on the client
The ssh-keygen command has an option to generate the user's private key in the PKCS #8 format that SunSSH clients in FIPS 140-2 mode require. For more information, see the ssh-keygen(1) man page.
For more information about FIPS 140-2 and SunSSH, see Using a FIPS 140-2 Enabled System in Oracle Solaris 11.3, Creating a Boot Environment With FIPS 140-2 Enabled in Managing Encryption and Certificates in Oracle Solaris 11.3, and the sshd(1M) man pages.
When you use a Sun Crypto Accelerator 6000 card for Secure Shell operations, SunSSH runs with FIPS 140-2 support at Level 3. Level 3 hardware is certified to resist physical tampering, use identity-based authentication, and isolate the interfaces that handle critical security parameters from the hardware's other interfaces.
In SunSSH, new keywords were added to enable you to control accepted public key types to disable weak key types. The default is to accept all key types.
The following new keywords have been added to SunSSH.
The following keywords have been added to the server configuration:
HostKeyAlgorithms
HostbasedAcceptedKeyTypes
PubkeyAcceptedKeyTypes
Kexalgorithms
For more information, see the sshd_config(4) man page.
The following keywords have been added to the SunSSH client configuration:
HostbasedAcceptedKeyTypes
PubkeyAcceptedKeyTypes
Kexalgorithms
For more information, see the ssh_config(4) man page.
X.509 certificates are a good choice for SunSSH authentication. They are the safest option for remote logins where interaction with the user is not permitted, such as when running remote scripts. Also, the user is not prompted to accept the host identity and the user public keys do not need to be present on the remote server.
When a user (a SunSSH client) tries to connect to the SunSSH server, the server passes the host certificate to the client. By using the public key of the Certificate Authority (CA) in the CA certificate, the client verifies the host certificate on the server against the digital signature associated with the CA.
X.509 certificate configuration requires the following steps:
The administrator generates an X.509 certificate for the server on the server that users will remotely log in to.
Users who plan to remotely log in to the server generate an X.509 certificate for themselves.
The administrator sends the public part of the server's root certificate to the administrator who configures users.
Every user sends the public part of their root certificate (referred to in SunSSH configuration files as a "Trusted Anchor" or TA) to the administrator of the remote server.
The server administrator stores the users' TA certificates where the ssh daemon can read them.
The user administrator stores the server's TA certificate where the ssh daemon can read it.
Then, users can use SunSSH to log in to the remote server.
You can also allow users to generate a self-signed trusted anchor (TA) certificate and sign it. Self-signed certificates are less secure. Users who self-sign certificates must be familiar with the technical and security issues around certificates.
For the procedure, see How to Add a CA Cert to Oracle Solaris (https://blogs.oracle.com/solaris/how-to-add-a-ca-cert-to-solaris-v2).