- Solaris 11 Ssh Connection Refused
- Solaris 11 Ssh Offline
- Solaris 11 Ssh Version
- Solaris 11 Ssh Maintenance
The post outlines steps to capture failed tty type logins such as telnet, rlogin, and terminal logins. This post does not cover logging Common Desktop Environment (CDE) logins or ssh logins. Invalid login attempts are logged to /var/adm/loginlog (if it exists) and/or syslog via the auth.notice facility.
How To Disable Openssl Ciphers In Solaris 10 and 11 (Doc ID 2338422.1) Last updated on SEPTEMBER 04, 2019. Applies to: Solaris Operating System - Version 10 1/13 U11 and later. Oracle Solaris 11 includes IPS, a new network-centric package management framework with automatic dependency checking. IPS has integrated package and patching, and can seamlessly manage system updates to Oracle Solaris Zones environments. Install a package called diagnostic/wireshark: # pkg install diagnostic/wireshark. When installing on Solaris version 11 running on the SPARC architecture, use the packages named: ssh-tectia-common-solaris-11-sparc.pkg.Z ssh-tectia-client-solaris-11-sparc.pkg.Z When installing on Solaris version 10 or 11 running on the x86-64 architecture, use the packages named.
/var/adm/loginlog
The /var/adm/loginlog file does not exist by default; it must be created. It must be owned by root and group sys, and must have read and write permissions for the owner only:
See loginlog manpage for additional info.
syslogd
Add a line similar to the following in /etc/syslog.conf:
Stop and restart syslogd after any changes to /etc/syslog.conf:
Solaris 9 and earlier
Solaris 10 and newer
The /etc/default/login environment variables
RETRIES=5 – This variable controls how many attempts before the tty line is disconnected. Keep in mind that this does not disable the account. The user can always reconnect and make another 5 attempts.
SYSLOG_FAILED_LOGINS=5 – This sets the number of failed attempts before logging via the auth.notice facility in syslog is done. Setting this variable to 0 (zero) will log all bad login attempts.
OpenSSH Implementation of Secure Shell
OpenSSH in Oracle Solaris is built on the latest version of the OpenSSH project, plus additions that are particular to the Oracle Solaris environment. To see which version of the OpenSSH project is the basis for OpenSSH on your system, run the pkg info openssh command.
Although SunSSH is the default, you can switch to the new OpenSSH implementation. You can use only one implementation at a time.
Caution - Beginning with the Oracle Solaris 11.3 SRU 5, OpenSSH has been upgraded to a version which requires active attention from system administrators. Review the changes in Oracle Solaris Modifications to OpenSSH and Oracle Solaris Additions to OpenSSH. |
Oracle Solaris Modifications to OpenSSH
Oracle Solaris makes the following changes to OpenSSH:
SunSSH Keywords Are Deprecated in OpenSSH
To ease the transition from SunSSH to OpenSSH, SunSSH-only options are available but deprecated in OpenSSH. OpenSSH ignores a deprecated option.
Deprecated server options include the following:
Deprecated client options include the following:
Secure Shell Protocol 1 Support Is Removed
Secure Shell Protocol 1 (v1) support is absent from OpenSSH on both the server side and the client side. If you have network entities that support only v1, such as old network routers, you can no longer connect to such devices by using OpenSSH. However, Oracle Solaris 10 users can still use SunSSH to access systems that use v1. And, Oracle Solaris 11.3 users can still use SunSSH to access systems that use v1.
Unsafe Algorithms Are Removed From OpenSSH
The default set of ciphers and MACs has been altered to remove unsafe algorithms. You can use the following commands to list all supported ciphers and MACs:
For more information, see the sshd_config(4) and ssh_config(4) man pages.
diffie-hellman-group1-sha1 Is Disabled by Default
Because the diffie-hellman-group1-sha1 key exchange is no longer considered secure, it is disabled on both the Secure Shell client and server sides.
If your servers support only diffie-hellman-group1-sha1, you should upgrade them to support diffie-hellman-group-exchange-sha256. Or, as a second choice, upgrade Oracle Solaris to a version which supports diffie-hellman-group14-sha1.
If upgrading the peer is not an option, users connecting to systems that do not support diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1, or diffie-hellman-group-exchange-sha1 can enable diffie-hellman-group1-sha1 as follows:
For the OpenSSH implementation of Secure Shell, the server administrator can allow logins from systems that do not support secure key exchange methods by explicitly enabling insecure key exchange methods. Add this line to the /etc/ssh/sshd_config file.
Then, restart the ssh SMF service on the server.
For additional information, see Using OpenSSH with Legacy SSH Implementations.
ssh-dss Keys Are Disabled by Default
Solaris 11 Ssh Connection Refused
Because the ssh-dss and ssh-dss-cert-* host and user key types are inherently weak, they are disabled by default at run time.
If you have been using ssh-dss keys for public key authentication, you should create new ssh-rsa keys and remove existing ssh-dss keys from all authorized_keys files. For instructions about creating new keys, see How to Generate a Public/Private Key Pair for Use With Secure Shell.
If ssh-rsa and ssh-dss host keys are not already present, svc:/network/ssh:default creates both. So, Oracle Solaris servers usually have ssh-dss host keys and ssh-rsa keys. In the rare cases where servers were provisioned with only an ssh-dss host key, you should add a ssh_rsa host key. If you cannot create the key, then the user needs to enable the ssh-dss key type on the command line to connect to the server by running the following command:
For additional information, see Using OpenSSH with Legacy SSH Implementations.
Default Value of UseDNS Is No in OpenSSH
If no UseDNS value is specified in the sshd_config file, the default value of UseDNS is No. The former default value provided no security benefit.
A UseDNS value of No means that you cannot use host names when configuring an ssh service.
You can explicitly specify UseDNS yes in the sshd_config file.
You can use IP addresses instead of host names in the sshd_config file as shown in the following examples.
In the Match block section of the sshd_config file, use an Address criterion instead of a Host criterion.
For example, you would replace Match Host somehost.domain with Match Address 192.0.2.11.
In the sshd_config entries for AllowUsers, AllowGroups, DenyUsers, and DenyGroups, use an IP address instead of the host name.
For example, you would replace AllowUsers jsmith@somehost.domain with AllowUsers jsmith@192.0.2.11.
In /etc/ssh/shosts.equiv or ~/.shosts entries, use an IP address instead of a host name.
For example, you would replace somehost.domain with 192.0.2.11.
In the ~/.ssh/authorized_keys entry, use an IP address instead of a host name when specifying the from option.
For example, you would replace from='somehost.domain' ssh-rsa AAAAB3...Q jsmith@work with from='192.0.2.11' ssh-rsa AAAAB3...Q jsmith@work.
You have two options:
Solaris 11 Ssh Offline
TCP Wrappers Are Not Supported in OpenSSH
OpenSSH does not support TCP wrappers. You will need to modify the sshd_config file or use a firewall to preserve a configuration that was previously enforced by TCP wrappers.
If you have been using TCP wrappers, you have been using /etc/hosts.allow or /etc/hosts.deny to allow or deny logins. Use the Match block in the sshd_config file to set up an equivalent configuration.
For example, to allow logins only from the 192.0.2.0/16 subnet, you might have set up TCP wrappers as follows:
The following entry in the sshd_config file sets an equivalent restriction:
Another option is to configure a firewall for access control. Settings similar to these examples can be enforced by a firewall. Firewall access control occurs before the network connection is established in the kernel.
Oracle Solaris Additions to OpenSSH
OpenSSH is an optional package, openssh, that you can install on your system. Although features have been added to the openssh implementation, it remains compatible with the OpenSSH project.
Solaris 11 Ssh Version
DisableBanner keyword – disables the display of a banner message from the Secure Shell client. For more information, see the ssh_config (4) man page.
PAM support – PAMServiceName and PAMServicePrefix keywords are available in the openSSH implementation.
Auditing support – OpenSSH generates Oracle Solaris audit records for login and logout.
Xforwarding – Is functional with non-writable home directories.
Proxy commands – For SOCKS5 and HTTP protocols work in SunSSH and in OpenSSH. For an example, see How to Set Up Default Secure Shell Connections to Hosts Outside a Firewall. The netcat utility provides similar functionality.
GSSAPI-Authenticated Diffie-Hellman Key Exchange – Is implemented as specified in RFC 4462.
Role login – Is implemented for host-based authentication if properly configured in PAM and sshd.
The following Oracle Solaris features have been added to the openssh implementation:
Unlike the OpenSSH project, which stores delegated credentials in a non-default credential cache such as /tmp/krb5cc_101_WO4082, the openssh implementation of Secure Shell uses a default credential cache such as /tmp/krb5cc_101.
Credentials in a default credential cache can be used to access NFS file systems that are protected by Kerberos.
For more information, see Managing Kerberos and Other Authentication Services in Oracle Solaris 11.3.
OpenSSH can run in FIPS 140-2 mode.
For more information, see OpenSSH and FIPS 140-2.
Delegated credentials in OpenSSH are stored differently on Oracle Solaris than the credentials are stored on other platforms.
OpenSSH and FIPS 140-2
Unlike SunSSH, OpenSSH enables FIPS 140-2 mode dynamically. If the OpenSSL library that OpenSSH links with is FIPS 140-2 capable, OpenSSH runs in FIPS 140-2 mode.
Solaris 11 Ssh Maintenance
See Example of Running in FIPS 140-2 Mode on an Oracle Solaris 11.3 SRU 5.6 System in Using a FIPS 140-2 Enabled System in Oracle Solaris 11.3.