Access the cluster using SSH
Suggest changes
PDFs
You can issue SSH requests to an ONTAP cluster to perform administrative tasks. SSH is enabled by default.
-
You must have a user account that is configured to use
sshas an access method.The
-applicationparameter of thesecurity logincommands specifies the access method for a user account. Learn more about thesecurity logincommand in the ONTAP command reference. -
If you use an Active Directory (AD) domain user account to access the cluster, an authentication tunnel for the cluster must have been set up through a CIFS-enabled storage VM, and your AD domain user account must also have been added to the cluster with
sshas an access method anddomainas the authentication method.
-
You must use an OpenSSH 5.7 or later client.
-
Only the SSH v2 protocol is supported; SSH v1 is not supported.
-
ONTAP supports a maximum of 64 concurrent SSH sessions per node.
If the cluster management LIF resides on the node, it shares this limit with the node management LIF.
If the rate of incoming connections is higher than 10 per second, the service is temporarily disabled for 60 seconds.
-
ONTAP supports only the AES and 3DES encryption algorithms (also known as ciphers) for SSH.
AES is supported with 128, 192, and 256 bits in key length. 3DES is 56 bits in key length as in the original DES, but it is repeated three times.
-
When FIPS mode is on, SSH clients should negotiate with Elliptic Curve Digital Signature Algorithm (ECDSA) public key algorithms for the connection to be successful.
-
If you want to access the ONTAP CLI from a Windows host, you can use a third-party utility such as PuTTY.
-
If you use a Windows AD user name to log in to ONTAP, you should use the same uppercase or lowercase letters that were used when the AD user name and domain name were created in ONTAP.
AD user names and domain names are not case-sensitive. However, ONTAP user names are case-sensitive. Case mismatch between the user name created in ONTAP and the user name created in AD results in a login failure.
-
Beginning with ONTAP 9.3, you can enable SSH multifactor authentication for local administrator accounts.
When SSH multifactor authentication is enabled, users are authenticated by using a public key and a password.
-
Beginning with ONTAP 9.4, you can enable SSH multifactor authentication for LDAP and NIS remote users.
-
Beginning with ONTAP 9.13.1, you can optionally add certificate validation to the SSH authentication process to enhance login security. To do this, associate an X.509 certificate with the public key that an account uses. If you log in using SSH with both an SSH public key and an X.509 certificate, ONTAP checks the validity of the X.509 certificate before authenticating with the SSH public key. SSH login is refused if that certificate is expired or revoked, and the SSH public key is automatically disabled.
-
Beginning with ONTAP 9.14.1, ONTAP administrators can add Cisco Duo two-factor authentication to the SSH authentication process to enhance login security. Upon first login after you enable Cisco Duo authentication, users will need to enroll a device to serve as an authenticator for SSH sessions.
-
Beginning with ONTAP 9.15.1, administrators can Configure dynamic authorization to provide additional adaptive authentication to SSH users based on the user's trust score.
-
From a host with access to the ONTAP cluster's network, enter the
sshcommand in one of the following formats:-
ssh username@hostname_or_IP [command] -
ssh -l username hostname_or_IP [command]
-
If you are using an AD domain user account, you must specify username in the format of domainname\\AD_accountname (with double backslashes after the domain name) or "domainname\AD_accountname" (enclosed in double quotation marks and with a single backslash after the domain name).
hostname_or_IP is the host name or the IP address of the cluster management LIF or a node management LIF. Using the cluster management LIF is recommended. You can use an IPv4 or IPv6 address.
command is not required for SSH-interactive sessions.
The following examples show how the user account named “joe” can issue an SSH request to access a cluster whose cluster management LIF is 10.72.137.28:
$ ssh joe@10.72.137.28 Password: cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
$ ssh -l joe 10.72.137.28 cluster show Password: Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
The following examples show how the user account named “john” from the domain named “DOMAIN1” can issue an SSH request to access a cluster whose cluster management LIF is 10.72.137.28:
$ ssh DOMAIN1\\john@10.72.137.28 Password: cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
$ ssh -l "DOMAIN1\john" 10.72.137.28 cluster show Password: Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.
The following example shows how the user account named “joe” can issue an SSH MFA request to access a cluster whose cluster management LIF is 10.72.137.32:
$ ssh joe@10.72.137.32 Authenticated with partial success. Password: cluster1::> cluster show Node Health Eligibility --------------------- ------- ------------ node1 true true node2 true true 2 entries were displayed.