Connect via sFTP third parties tools to a SAS grid node

[mbertol4]

Hi, we have a SAS grid with 8 grid nodes linux boxes, users wants to connect via sFTP third parties tool to the SAS grid nodes to browse files present in amounted file system.  It looks like there is an extra authentication layer handled by the Metadata tier that is applied to those sFTP connection. Do you have any reference to specific documentation mentioning this additional authentication layer that looks to be applied only if connection is done via third parties sFTP tools ?

Thanks

Kind regards.

[Patrick]

Except for the SAS binaries and some config files wouldn't most of your files/data be stored on a shared file system like gpfs, lustre, etc. that's mounted to the grid nodes? If so then where comes SAS into play for 3rd party sftp access to the shared file system?

[mbertol4]

Indeed Lustre filesystem is mounted on the SAS grid nodes, that’s the reason of the sFTP access from users to be able to browse the mounted Lustre filesystem from sFTP client.

Thanks

[Patrick]

So you just need to be able to create an sFTP connection to one of the grid nodes where Lustre is mounted with a user that got sufficient permissions to browse the file system and you should be good to go. No SAS involved. 

Answer from chatGPT:

To establish an SFTP (Secure File Transfer Protocol) connection to a server, several components and settings must be enabled:

1. SFTP Server: The server must have an SFTP server software or service running. This is typically part of the SSH server package, such as OpenSSH, which supports SFTP by default.

2. SSH Access: Since SFTP operates over SSH, the SSH service must be enabled on the server. Ensure that the SSH daemon (e.g., sshd on Linux) is running.

3. Firewall Rules: Ensure that the firewall settings on the server allow incoming connections on port 22 (the default port for SSH and SFTP). If the server is using a different port for SSH, you need to configure the firewall to allow that port.

4. User Permissions: The user account you are using to connect must have the necessary permissions to access the directories and files you want to transfer. Ensure that the user is correctly configured on the server.

5. SFTP Client: On the client side, you need an SFTP client application or command-line tool. Common options include command-line tools like sftp or graphical clients like FileZilla or WinSCP.

6. Authentication: The authentication method must be set up correctly. This usually involves:

   • Password Authentication: Ensure that the user’s password is correct and that the server allows password-based authentication (this can be disabled for security reasons).
   • Public Key Authentication: If using public key authentication, ensure that the server has the client’s public key in the ~/.ssh/authorized_keys file and that the private key is properly configured on the client side.

7. Configuration Files: Ensure that the server’s SSH configuration file (/etc/ssh/sshd_config on Linux) allows SFTP connections. Look for lines like Subsystem sftp /usr/lib/openssh/sftp-server or similar, and verify that SFTP is enabled.

By ensuring these components and settings are properly configured, you can successfully establish an SFTP connection to a server.

[mbertol4]

But from Copilot I get the below, now the question is: is there are specific additional authentication layer that is triggered while connecting to the SAS grid node via third parties sFTP client ?





The involvement of the SAS Metadata Server in the authentication process is specific to how SAS manages user identities and permissions, and it can apply to both SFTP and SSH connections, depending on how the environment is configured. However, there are some distinctions:

1. SFTP Connections:

* When using SFTP, especially in a SAS environment, the metadata server can be involved to ensure that the user has the appropriate permissions to access the requested resources. This is because SFTP is often used for transferring data, and SAS needs to ensure that data access policies are enforced.
* The metadata server can provide additional layers of security, such as role-based access control and logging of access requests, which are crucial for compliance and security.
2. SSH Connections:

* Standard SSH connections typically rely on the underlying operating system for user authentication and do not necessarily involve the SAS Metadata Server. SSH is primarily used for remote command execution and management, and it uses the system’s user accounts and permissions.
* However, if SSH is used to access SAS resources or execute SAS scripts, the metadata server might still play a role in verifying that the user has the necessary permissions within the SAS environment.

In summary, while the metadata server’s involvement is more pronounced and necessary for SFTP connections due to the nature of data transfers and access control, it can also be relevant for SSH connections if they interact with SAS resources. The key difference lies in the specific use case and how the SAS environment is configured to handle authentication and authorization.

[Patrick]

If you don't intent to remotely spawn SAS processes via sFTP then I can't think of any reason why the SAS Metadata Server should be involved.

SAS files (tables) as such are just files on a file system. To open them you need of course software that can open them and you would need to download them to the client side for opening (eg. with the SAS Universal Viewer). 

What worked for me over many years for development in a SAS client/server environment (whether Grid or not) is a combination of SAS EG/Studio, WinSCP and Putty (or MobaXterm). 

A scp or sFTP connection without any SAS layer involved has also the advantage that it's still working when the SAS services are down.