PowerScale OneFS: Configuring SFTP and setting up chroot
Summary: This document describes how to allow access to the PowerScale cluster over Secure File Transfer Protocol (SFTP).
Instructions
This document describes how to allow access to the PowerScale cluster over SFTP. There are some limitations and considerations to keep in mind when beginning this process.
- Users/Groups that need SFTP access must have the
ISI_PRIV_LOGIN_SSHprivilege associated with their user. - SSH and SFTP access only work within the System zone.
- Not all ssh configuration options are available; PowerScale supports Match and Subsystem statements over the
isi ssh modifycommand set.
Outside of these factors, PowerScale operates as any other FreeBSD OpenSSH server. Check the OpenSSH version on a cluster using the command ssh -V.
For guidance on setting up roles and privileges, consult the CLI or Web Administration guides for your release under the 'Administrative roles and privileges' section.
Checking if a user/group has ISI_PRIV_LOGIN_SSH
Verify that the user in question has ISI_PRIV_LOGIN_SSH. Below is an example with the default admin user.
p930-1# isi auth mapping token admin | grep "LOGIN_SSH"
ISI_PRIV_LOGIN_SSH
If there is no output, the user must be assigned to a Role that includes that Privilege. More details on how to do so is found in our Administration Guides for your relevant release under "Administrative roles and privileges"
Basic SFTP access for local users
After verifying correct privileges, users should have SFTP access to parts of the file system based on their user-mapping token.
p930-1# sftp admin@localhost
(admin@localhost) Password:
Connected to localhost.
sftp> dir
sftp> cd ..
sftp> dir
admin ftp
Basic Chroot SFTP access
To limit a user to a specific subset of the file system, use OpenSSH's ChrootDirectory functionality within a Match statement. This causes the client to see their login path as / and makes it so they cannot leave that subset of the file system. ChrootDirectory does however have strict directory permission requirements on the entire path to the ChrootDirectory that every directory in the path has Posix Permissions of root:wheel drwxr-xr-x for more details on this, refer to the OpenSSH maintainers man page.
Here is a common Match statement for implementing ChrootDirectory while matching a group. The first three lines are required for ChrootDirectory without supporting files. The last line limits a user's ability to take advantage of X11Forwarding features within OpenSSH.
Match Group admin
ChrootDirectory /ifs/sftp
ForceCommand internal-sftp
X11Forwarding no
Below is a basic example of preparing a path for chroot when any matching users can write to the /ifs/sftp/home directory. root:wheel owns the directories /ifs and /ifs/sftp, with permissions set to 755 for ChrootDirectory while /ifs/sftp/home has permissions of 777, allowing user write access.
p930-1# isi auth settings acls modify --calcmode-group=group_only --calcmode-owner=owner_only
p930-1# mkdir -p /ifs/sftp/home
p930-1# chmod 755 /ifs/
p930-1# chmod 755 /ifs/sftp
p930-1# chmod 777 /ifs/sftp/home
p930-1# isi ssh settings modify --match="Match Group admin
dquote> ChrootDirectory /ifs/sftp
dquote> ForceCommand internal-sftp"
p930-1# sftp admin@localhost
(admin@localhost) Password:
Connected to localhost.
sftp> ls
home
sftp> pwd
Remote working directory: /
Configuring multiple Match Strings
It is easier to manage multiple matches in a file and then pass them to our isi ssh commands. Using this process ensures sshd validates the file and only applies the change if it is valid.
Below are examples of success and failure.
p930-1# cat /ifs/sshMatches
Match Group admin
ChrootDirectory /ifs/sftp
ForceCommand internal-sftp
X11Forwarding no
Match All
X11Forwarding no
p930-1# sshd -t -f /ifs/sshMatches && isi ssh settings modify --match="$(cat /ifs/sshMatches)"
p930-1# sshd -t -f /ifs/sshMatchBad && isi ssh settings modify --match="$(cat /ifs/sshMatchBad)"
Missing Match criteria for Allk
/ifs/sshMatchBad line 6: Bad Match condition
Match String Considerations.
When setting up Match Strings, any user or group identifier that the cluster is aware of can be used in a "Match User" or "Match Group" string. So referencing Active Directory groups can be done with RFC2307 by domain\user.
If a user is not routing to the correct path or settings in a Match User string, verify that the user can be looked up on the cluster with the command isi auth mapping token <username> taking username from your Match String.
If a user is not routing to the correct path or settings in a Match Group string, verify that the user is a member of the group in question with the command isi auth mapping token <username> | grep <groupname>.
Provide a username and take the group name from the Match String.
Below is an example of a user who is not correctly routing to a path due to a mistake in the Match Group statement. User stateroot is not working correctly while the user prodroot is, correct the mistake in the group name used in the Match Group statement to fix this.
p930-1# isi auth mapping token stageroot | grep "LOGIN_SSH"
ISI_PRIV_LOGIN_SSH
p930-1# isi auth mapping token prodroot | grep "LOGIN_SSH"
ISI_PRIV_LOGIN_SSH
p930-1# cat /ifs/sshMatches
Match Group Stage-Root-SFTP
ChrootDirectory /ifs/home/Stage-Root
X11Forwarding no
ForceCommand internal-sftp
Match Group Prod-Root
ChrootDirectory /ifs/home/Prod-Root
X11Forwarding no
ForceCommand internal-sftp
p930-1# isi auth mapping token stageroot | grep "Stage-Root-SFTP"
p930-1# isi auth mapping token prodroot | grep "Prod-Root"
Name: Prod-Root
p930-1# isi auth mapping token stageroot | grep "Stage-Root"
Name: Stage-Root
Legacy Configurations
Before OneFS 8.2 this same functionality could be accomplished, but the isi ssh command did not yet exist. Instead of using isi ssh settings modify --match="" edit the file /etc/mcp/templates/sshd_config with the same Match Strings the steps above would use. Add them to the end of /etc/mcp/templates/sshd_config.
The directions provided should work for OneFS versions before OneFS 8.2, but any configuration adjustments done in this manner will be removed after upgrading to a OneFS version with Application Programming Interface (API) support. Users that use SFTP access still require the ISI_PRIV_LOGIN_SSH privilege.