OneFS 8.2 includes a number of security enhancements to reduce risk and provide tighter access control. Among them is support for Multi-factor Authentication, or MFA. At its essence, MFA works by verifying the identity of all users with additional mechanisms, or factors - such as phone, USB device, fingerprint, retina scan, etc - before granting access to enterprise applications and systems. This helps corporations to protect against phishing and other access-related threats.


multi-factor_auth_1.png

 

The SSH protocol in OneFS 8.2 now incorporates native support for the external Cisco Duo service for unified access and security to improve trust in the users and the storage resources accessed. The SSH protocol is configured using the CLI and now can be used to store public keys in LDAP rather than stored in the user’s home directory. A key advantage to this architecture is the simplicity in setup and configuration which reduces the chance of mis-configuration.


The Duo service that provides MFA access can be used in conjunction with password and/or keys to provide additional security. The Duo service delivers maximum flexibility by including support for the Duo App, SMS, voice and USB keys. As a failback, specific users and groups in an exclusion list may be allowed to bypass MFA, if specified on the Duo server. It is also possible to generate one-time access to users to accommodate events like a forgotten phone or failback mode associated with the unavailability of the Duo service.


With 8.2, OneFS’ SSH protocol implementation:


  • Supports Multi-Factor Authentication (MFA) with the Duo Service in conjunction with passwords and/or keys
  • Is configurable via the OneFS CLI (No WebUI support yet)
  • Can now use Public Keys stored in LDAP


Multi-factor Authentication helps to increase the security of their clusters and is a recommended best-practice for many public and private sector industry bodies, such as the MPAA.

OneFS 8.2 introduces support for MFA with Duo, CLI configuration of SSH and support for storing public SSH keys in LDAP. A consistent configuration experience, heightened security and tighter access control for SSH is a priority for many customers.

 

In prior releases, the OneFS SSH authentication process worked as follows:


Step

Action

1

Administrator manually configures the User Authentication Method. If configuring Public/Private Key only, there is an opportunity for misconfiguration.

2

If a key is required, a user’s Private Key is provided at start of session. This is verified first against users Public Key from their home directory on the cluster (provisioned previously by a cluster admin).

3

If a password is required, the SSH server requests the user’s password, which is sent to PAM and verified against the password file or LSASS.

4

The user is checked for the appropriate RBAC SSH privilege.

5

If all of the above steps succeed, the user is the granted SSH access.

 

However, in OneFS 8.2, the enhanced SSH authentication process is as follows:


Step

Action

1

Administrator configures User Authentication Method. If configuring ‘publickey’, the correct settings are set for both SSH and PAM.

2

If User Authentication Method is ‘publickey’ or ‘both’, user’s Private Key is provided at start of session. This is verified first against the Public Key from either their home directory on the cluster the LDAP Server.

3

If Duo is enabled, the user’s name is sent to the Duo Service.

  • If the Duo config has Autopush set to yes, a One Time Key is sent to the user on the set device.
  • If the Duo config has Autopush set to no, the user chooses from a list of devices linked to their account and a One Time Key is sent to the user on that device.
  • The user enters the key at the prompt, and the key is sent to Duo for verification.

4

If User Authentication Method is ‘password’ or ‘both’, the SSH server requests the user’s password, which is sent to PAM and verified against the password file or LSASS.

5

The user is checked for the appropriate RBAC SSH privilege

6

If all of the above steps succeed, the user is SSH granted access.

 

A new CLI command family is added to view and configure SSH, and defined authentication types help to eliminate misconfiguration issues. Any SSH config settings that are not exposed by the CLI can still be configured in the SSHD configuration template. In addition, Public Keys stored in LDAP may now also be used by SSH for authentication. There is no WebUI interface for SSH yet, but this will be added in a future release.

With 8.2, many of the common SSH settings can now be configured and displayed via the OneFS CLI using ‘isi ssh settings modify’ and ‘isi ssh settings view’ commands respectively.


The authentication method is configured with the option ‘--user-auth-method’, which can be set to ‘password’, ‘publickey’, ‘both’ or ‘any’. For example:


# isi ssh settings modify -–login-grace-time=1m -–permit-root-login=no –-user-auth-method=both

# isi ssh settings view

                   Banner:

                  Ciphers: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com

Host Key Algorithms: +ssh-dss,ssh-dss-cert-v01@openssh.com

Ignore Rhosts: Yes

Kex Algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

Login Grace Time: 1m

                Log Level: INFO

                     Macs: hmac-sha1

Max Auth Tries: 6

Max Sessions: -

Max Startups:

Permit Empty Passwords: No

Permit Root Login: No

                     Port: 22

Print Motd: Yes

Pubkey Accepted Key Types: +ssh-dss,ssh-dss-cert-v01@openssh.com

Strict Modes: No

                Subsystem: sftp /usr/local/libexec/sftp-server

Syslog Facility: AUTH

Tcp Keep Alive: No

   Auth Settings Template: both

 

On upgrade to 8.2, the cluster’s existing SSH Config will automatically be imported into gconfig. This includes settings both exposed and not exposed by the CLI. Any additional SSH settings that are not included in the CLI config options can still be manually set by adding them the /etc/mcp/templates/sshd.conf file. These settings will be automatically propagated to the /etc/ssh/sshd_config file by mcp and imported into gconfig.


To aid with auditing or troubleshooting SSH, the desired verbosity of logging can be configured with the option ‘--log-level’, which accepts the default values allowed by SSH.


The ‘--match’ option allows for one or more match settings block to be set, for example:


# isi ssh settings modify –-match=”Match group sftponly

dquote>      X11Forwarding no

dquote>      AllowTcpForwarding no

dquote>      ChrootDirectory %h”

 

And to verify:


# less /etc/ssh/sshd_config

# X: ----------------

# X: This file automatically generated. To change common settings, use 'isi ssh'.

# X: To change settings not covered by 'isi ssh', please contact customer support.

# X: ----------------

AuthorizedKeysCommand /usr/libexec/isilon/isi_public_key_lookup

AuthorizedKeysCommandUser nobody

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.# X: ----------------

# X: This file automatically generated. To change common settings, use 'isi ssh'.

# X: To change settings not covered by 'isi ssh', please contact customer support.

# X: ----------------

AuthorizedKeysCommand /usr/libexec/isilon/isi_public_key_lookup

AuthorizedKeysCommandUser nobody

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.

com,chacha20-poly1305@openssh.com

HostKeyAlgorithms +ssh-dss,ssh-dss-cert-v01@openssh.com

IgnoreRhosts yes

KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1

LogLevel INFO

LoginGraceTime 120

MACs hmac-sha1

MaxAuthTries 6

MaxStartups 10:30:60

PasswordAuthentication yes

PermitEmptyPasswords no

PermitRootLogin yes

Port 22

PrintMotd yes

PubkeyAcceptedKeyTypes +ssh-dss,ssh-dss-cert-v01@openssh.com

StrictModes yes

Subsystem sftp /usr/local/libexec/sftp-server

SyslogFacility AUTH

UseDNS no

X11DisplayOffset 10

X11Forwarding no

Match group spftonly

X11Forwarding no

AllowTcpForwarding no

ForceCommand internal-sftp -u 0002

ChrootDirectory %h

 

Note that match blocks usually span multiple lines, and the ZSH shell will allow line returns and spaces until the double quotes (“) are closed.


When making SSH configuration changes, the SSH service will be restarted, but existing sessions will not be terminated. This allows for changes to be tested before ending the configuration session. Be sure to test any changes that could affect authentication before closing the current session.


A user’s public key may be viewed by adding ‘--show-ssh-key’ flag. Multiple keys may be specified in the LDAP configuration, and the key that corresponds to the private key presented in the SSH session will be used (unless there is no match of course). However, the user will still need a home directory on the cluster or they will get an error upon log-in.


OneFS can now be configured to use Cisco’s Duo MFA with SSH. Duo MFA supports the Duo App, SMS, Voice and USB Keys.


multi-factor_auth_2.png


Be aware that the use of Duo requires an account with the Duo service. Duo will provide a host, ‘ikey’ and ‘skey’ to use for configuration, and the skey should be treated as a secure credential.


From the cluster side, multi-factor auth support with Duo is configured via the ‘isi auth duo’. For example, the following syntax will enable Duo support in safe mode with autopush disabled, set the ikey, and prompt interactively to configure the skey:


# isi auth duo modify -–autopush=false -–enabled=true -–failmode=safe -–host=api.9283eefe.duosecurity.com -–ikey=DIZIQCXV9HIVMKYZ8V4S -–set-skey

Enter skey:

Confirm:

 

Similarly, the following command will verify the cluster’s Duo config settings:


# isi auth duo view -v

         Autopush: No

          Enabled: Yes

         Failmode: safe

Fallback Local IP: No

           Groups:

       HTTP Proxy:

    HTTPS Timeout: 0

          Prompts: 3

         Pushinfo: No

             Host: api.9283eefe.duosecurity.com

             Ikey: DIZIQCXV9HIVMKYZ8V4S

 

Duo MFA rides on top of existing password and/or public key requirements and therefore cannot be configured if the SSH authentication type is set to ‘any’. Specific users or groups may be allowed to bypass MFA if specified on the Duo server, and Duo allows for the creation of one time or date/time limited bypass keys for a specific user.


Note that a bypass key will not work if ‘autopush’ is set to ‘true’, since no prompt option will be shown to the user. Be advised that Duo uses a simple name match and is not Active Directory-aware. For example, the AD user ‘DOMAIN\foo’ and the LDAP user ‘foo’ are the considered to be one and the same user by Duo.


Duo uses HTTPS for communication with the Duo server and there is an option to set a proxy to use if needed. Duo also has a failback mode specifying what to do if the Duo service is unavailable:


Failback Mode

Characteristics

Safe

In safe mode SSH will allow normal authentication if Duo can not be reached.

Secure

In secure mode SSH will fail if Duo can not be reached. This includes ‘bypass’ users, since the bypass state is determined by the Duo service.

 

The Duo ‘autopush’ option controls whether a key will be automatically pushed or if a user can choose the method:


Autopush Option

Characteristics

Yes

If set to yes, Duo will push the one-time key to the device associated with the user.

No

If set to no, Duo will provide a list of methods to push the one-time key to.

Pushinfo

The Pushinfo option allows a small message to be sent to the user along with the one-time key as part of the push notification.

 

Duo may be disabled and re-enabled without re-entering the host, ikey and skey.


The ‘groups’ option groups may be used to specify one or more groups to be associated with the Duo Service and can be used to create an exclusion list. Three types of groups may be configured:


Group Option

Characteristics

Local

Local groups using the local authentication provider.

Remote

Remote authentication provider groups, such as LDAP.

Duo

Duo Groups created and managed though the Duo Service.

 

A Duo group can be used to both add users to the group and specify that its status is ‘Bypass’. This will allow users of this group to SSH in without MFA. Configuration is within Duo itself and the users must already be known to the Duo service. The Duo service must still be contacted to determine whether the user is in the bypass group or not.


Using a local or remote authentication provider group allows users without a Duo account to be added to the group. If a user is in a group that has been added to the Isilon Duo the user can SSH into the cluster without a Duo account. The created account can then be approved by an administrator at which time the user can SSH into the cluster.


It is also possible to create a local or remote provider group as an exclusion group by configuring it via the CLI with a ‘!’ before it. Any user in this group will not be prompted for a Duo key. Note that ZSH, OneFS’ default CLI shell, typically requires the ‘!’ character to be escaped.


This exclusion is checked by OneFS prior to contacting Duo. This is one method of creating users that can SSH into the cluster even when the Duo Service is not available and failback mode is set to secure. If using such an exclusion group, it should be preceded by an asterisk to ensure that all other groups do required the Duo One Time Key. For example:


# isi auth duo modify --groups=”*,\!duo_exclude”

# isi auth duo view -v

Autopush: No

Enabled: No

Failmode: safe

Fallback Local IP: No

Groups: *,!duo_exclude

HTTP Proxy:

HTTPS Timeout: 0

Prompts: 3

Pushinfo: No

Host: api-9283eefe.duosecurity.com

Ikey: DIZIQCXV9HIVMKYZ8V4S


The ‘groups’ option can also be used to specify users that are required to use Duo while users not in the group do not need to. For example: “--groups=<group>”.


The following output shows a multi-factor authenticated SSH session to a cluster running OneFS 8.2 using a passcode:


# ssh duo_user1@isilon.com

Duo two-factor login for duo_user1

 

Enter a passcode or select one of the following options:

 

1. Duo Push to iOS

2. Duo Push to XXX-XXX-4237

3. Phone call to XXX-XXX-4237

4. SMS passcodes to XXX-XXX-4237 (next code starts with: 1)

Passcode or option (1-4): 907949100

  1. Success. Logging you in…

Password:

Copyright (c) 2001-2017 EMC Corporation. All Rights Reserved.

Copyright (c) 1992-2017 The FreeBSD Project.

Copyright (c) 1979, 1980. 1983, 1986, 1989, 1991, 1992, 1993, 1994

     The Regents of the University of California. All rights reserved.

Isilon OneFS v8.2.0

 

With 8.2, it is now possible to use Public SSH keys from LDAP rather than from a user’s home directory on the cluster. For example:


# isi auth users view –-user=ssh_user_1 –-show-ssh-keys

                    Name: ssh_user1_rsa

                      DN: cn-ssh_user1_rsa,ou=People,dc=tme-ldap1dc=isilon,dc=com

DNS Domain: -

                  Domain: LDAP_USERS

                Provider: lsa-ldap-provider:tme-ldap1

Sam Account Name: ssh_user1_rsa

                     UID: 4567

                     SID: S-1-22-1-4567

                 Enabled: Yes

                 Expired: No

                  Expiry: -

                  Locked: No

                   Email: -

                   GECOS: The private SSH key for this user may be found at isilon/tst/ssh_tst_keys. The key type will match the end of the user name (rsa in this case)

Generated GID: No

Generated UID: No

Generated UPN: -

Primary Group

                          ID: GID:4567

                        Name: ssh_user1_rsa

          Home Directory: /ifs/home/ssh_user1_rsa

Max Password Age: -

Password Expired: No

Password Expiry: -

Password Last Set: -

Password Expires: Yes

                   Shell: /usr/local/bin/zsh

                     UPN: -

User Can Change Password: No

         SSH Public Keys: ssh-rsa AAAAB3Nza……………

 

The LDAP create and modify commands also now include the ‘--ssh-public-key-attribute’ option. The most common attribute for this is the sshPublicKey attribute from the ldapPublicKey objectClass.