Privileged SSH Sessions:
Creating secure PAM SSH sessions with or without the use of Native Client Side Applications.
For far too long, IT departments gave the actual secrets (logins, passwords, ssh keys or passphrases) to administrators, developers or outside contractors that needed access to their business’s privileged systems and endpoints.
These secrets were often shared via emails, Excel files, SharePoint lists or countless other methods which clearly opened a glaring hole in any corporate security policy.
Not to mention, how could these secrets ever been changed or updated without negatively impacting these users’ workflows.
The downsides and security risks are obvious, but what other option is there?
Imprivata Privileged Access Management
Meet Privileged Access Management (PAM).
With PAM you can easily allow administrators, developers and contractors to create secure, privileged and recorded sessions to remote endpoints using the SSH or SFTP protocol without providing the passwords, keys or passphrases.
And most importantly, this can be accomplished directly in their desktop or mobile web browser (with no additional requirements) or using their existing native desktop SSH clients like PuTTY, WinSCP, OpenSSH or SecureCRT.
PAM secures your sensitive connection secrets in its Identity Vault, you share access to these secrets (but not the actual secrets themselves) with selected users and they simply Connect to the endpoint.
You decide who, where and when the access is granted and PAM will connect, audit and record their activity and even rotate the passwords as needed.
It doesn’t get much easier or more secure than that!
PAM provides secure, privileged SSH access to your server and endpoints with the following methods:
- Directly in your web browser without the need of client side agents or applications.
- Natively using your own client side applications like PuTTY or SecureCRT.
- Remote App technology that provide a Jump Server like native application experience.
Secure PAM SSH session in your browser (left) and in a native desktop client like PuTTY (right)
Use PAM
Use PAM instead of others Password Vaults or Session Brokers.
Others typically require heavy server installs and agents (or modified clients) in order to create such remote sessions, while others have limited support for remote protocols or don’t offer password resets or rotation.
PAM creates a streamlined approach to:
- Establishing secure, “password-less” access to remote endpoints without agents
- Providing access to multiple endpoints with only the user’s personal login account
- Eliminating the use of shared accounts
- Allowing the continued use of common desktop SSH clients like PuTTY
- Auditing user activity during their connected sessions with reporting and notification options
- Recording keystrokes and file transfer operations
- Enforcing limited or time restricted user access via configured access request workflows
- Randomizing passwords as needed based on time or event based policies
- Providing users with access to privileged systems without disclosing the secrets to them
- Maintaining all endpoint details, secrets and information in a secure, 256-bit encrypted Vault
PAM Accomplishing
How does PAM accomplish this?
PAM brokers the SSH connections through its Session Manager module in order to secure the login credentials, enforce the permissions and workflow requirements and overlay the auditing, recording and reporting functionality with the session.
To better explain how it works, let’s create a simple example scenario.
Bob, your outside contractor, needs to login to your Ubuntu web server to resolve an issue. You don’t feel comfortable providing Bob with login information (password, key or passphrase) and you don’t really have the time to “watch” over him, so you give him access to your web server in PAM and let it secure Bob’s activities.
Now all Bob has to do is securely login into PAM (optionally with MFA or 2FA) and find this shared web server record.
He opens the record and simply clicks the Connect button to open a remote session directly in his browser, no agents or clients required.
PAM establishes the connection using the details in the record, which Bob cannot see nor copy, and then hands control over to him.
Bob works on the server to resolve the issue and when down he simply logs out all while PAM is monitoring and recording his activities in the background.
Alternatively, if Bob prefers to use his native PuTTY client he simply creates a session to PAM, specifying the web server’s record ID and his PAM login credentials, and PAM will broker the connection and create the remote session to the server directly in PuTTY.
So Bob can jump between his PuTTY session, use his familiar shortcuts and formatting, work on your web server all without him knowing the actual server secrets.
Please review the following articles to further understand how to configure secure, remote SSH sessions in PAM.
Create secure, password-less SSH sessions in your web browser
