The SSH Proxy Service (SSHP) provides a secure, centralized proxy for SSH access to internal UBC systems. Instead of exposing internal SSH services directly to the internet, users connect through a controlled host that enforces authentication and access controls - improving security and compliance across the university’s infrastructure.
Note: This service is intended for user activities using User Accounts. It is not a replacement for the UBC Privileged Access Management (PAM) service, which is the correct solution for system administration using Privileged Accounts. If you are an administrator, you are encouraged to enroll your server into PAM. See the “How does this service compare to PAM?” question in the FAQs for more information
Features and Benefits
| Feature | Benefits |
| Secure Encrypted Access UBC ISS U3 § 3.1.8 UBC ISS M10 | All connections use SSH encryption to protect data in transit. Users connect through the proxy rather than directly to internal servers, reducing the attack surface. |
| Secure File Transfers UBC ISS U3 § 3.1.8 UBC ISS U6 § 2.1.1 UBC ISS M10 | Supports SCP and SFTP for secure file transfers to and from internal systems through the proxy. |
| Multi-Factor Authentication UBC ISS U2 § 7.1 | Uses CWL with MFA to verify user identity before granting access to internal resources. |
| Flexible Authentication UBC ISS U2 UBC ISS M2 | Supports both interactive (password + MFA) and key-based authentication methods (MFA required for key registration). |
| Logging & Compliance UBC ISS M8 § 2.4 | Maintains logs of login attempts, authentication activity, and accessed destination hosts for security auditing, troubleshooting, and compliance. |
| Access Control UBC ISS M2 § 2.4 UBC ISS M10 | Access is granted on the Principle of Least Privilege. Destination hosts must be registered before users can connect. Access is limited to authorized internal systems only, in compliance with security architecture and user account management standards. |
| High Availability | The service is deployed with redundancy to ensure continuous availability. |
| Service Availability | 24/7 |
Requirements and Eligibility
The SSH Proxy Service is automatically provisioned for active UBC students, staff, and faculty. It is also available upon request to other users who have a UBC CWL account with UBC MFA.
Price
No cost
Sign-Up Requirements
- An active CWL account with multi-factor (MFA) enabled
- An SSH client installed on your device
- A registered SSH Destination Host that you are authorized to access
To maintain the security of internal systems, the following requirements apply:
- Use of this proxy service may be monitored and recorded for troubleshooting and security purposes, in accordance with UBC's Information Systems Policy (SC14).
- Proxy monitoring is limited to activity on the proxy service itself and does not include activity on Destination Hosts, which may be monitored separately by the administrators of the Destination Host.
- Repeated failed authentication attempts from the same IP address will result in a temporary automatic block.
- SSH sessions do not have a defined idle timeout. However, sessions may be disconnected during scheduled maintenance, patching activities, or service interruptions.
- SSH keys are equivalent to UBC credentials and must be protected in compliance with UBC ISS U2. SSH keys and passwords must not be shared.
- SSH Destination Hosts may only be registered for systems that are authorized to use the service and are managed in accordance with UBC Information Security Standards.
Further Information
Typical Use Cases
- Students accessing academic computing resources
- Faculty and researchers accessing research computing environments
- Developers connecting to internal development and testing systems
- Staff accessing internal SSH-enabled services
- Authorized external collaborators or affiliates (upon approval)
When to Use SSH Proxy
- You need to access an SSH-enabled UBC system from outside the UBC network.
- You need to securely transfer files to or from a registered SSH Destination Host.
- You need command-line access to a registered SSH Destination Host.
- You need to access a UBC system that requires multi-factor authentication for SSH access.
When NOT to Use SSH Proxy
- You require system administrative access using privileged accounts. Use the UBC Privileged Access Management service instead.
- You need to access systems that are not registered as SSH Destination Hosts.
- You need to access systems outside of UBC-managed networks.
Getting Started
Access to the SSH Proxy Service is automatically provisioned for eligible UBC faculty, staff, and students. Once provisioned, users can begin using the service by following the guidance in the Technical Documentation linked below.
SSH keys used with this service must be registered through the SSH Proxy Key Registration Portal.
If you do not have access to the service and believe you require it, submit a Cybersecurity Services Support Request through the UBC Self-Service Portal.
To onboard an SSH Destination Host for access through the SSH Proxy Service, SSH Destination Host administrators can submit an SSHP Onboarding request through the Cybersecurity Services section of the UBC Self-Service Portal.
Tested SSH Clients
| Platform | Client |
| Windows | OpenSSH (via Windows Terminal / PowerShell), PuTTY |
| macOS | OpenSSH |
| Linux | OpenSSH (default on most distributions) |
Further Information
Resource | Login Required | Accessible From |
None | Anywhere | |
CWL | Anywhere |
Responsibility
This chart describes the shared responsibility model for the SSH Proxy Service. It outlines which responsibilities belong to Clients, the SSH Proxy Service, and Destination SSH Host Administrators when managing SSH access through the service.
Area of Responsibility | Client | SSH Proxy Service | SSH Destination Host Administrators |
Configure client systems to connect through the SSH Proxy Service using supported SSH ProxyJump or -J configuration. | ✅ | ❌ | ❌ |
Maintain local SSH client configuration, including the correct proxy username, destination username, destination hostname, and identity files. | ✅ | ❌ | ❌ |
Avoid SSH agent forwarding unless specifically required and understood. | ✅ | ❌ | ❌ |
Generate, protect, rotate, and register SSH public keys used for non-interactive authentication to the SSH Proxy Service. | ✅ | ❌ | ❌ |
Generate, protect, rotate, and register SSH public keys used for non-interactive authentication to the SSH Destination Host. | ✅ | ❌ | ❌ |
Request access to SSH Destination Hosts through the appropriate SSH Destination Host Administrator. | ✅ | ❌ | ✅ |
Use UBC PAM, rather than SSH Proxy, for privileged system administration where privileged access controls, session recording, or credential management are required. | ✅ | ❌ | ✅ |
Troubleshoot authentication, authorization, shell, application, file transfer, or protocol issues after the connection reaches the SSH Destination Host. | ✅ | ❌ | ✅ |
Create, maintain, disable, and remove user accounts on SSH Destination Hosts. | ❌ | ❌ | ✅ |
Manage SSH Destination Host SSH host keys and communicate expected host key changes to clients. | ❌ | ❌ | ✅ |
Configure SSH Destination Host SSHD service, host firewall rules, local access controls, MFA, and destination-side logging. | ❌ | ❌ | ✅ |
Ensure that the SSH Destination Hosts are compliant with UBC’s Information Security Standards. | ❌ | ❌ | ✅ |
Troubleshoot failures that occur before the SSH Proxy Host connection is successfully established. | ✅ | ✅ | ❌ |
Authenticate users to the SSH Proxy Service and enforce SSH Proxy Host access rules that restrict which SSH Destination Hosts may be reached. | ❌ | ✅ | ❌ |
Operate and maintain the SSH Proxy Hosts and SSH Proxy Key Registration Portal. | ❌ | ✅ | ❌ |
Provide proxy-side logging and monitoring for SSH Proxy Service activity. | ❌ | ✅ | ❌ |
Ensure that the SSH Proxy Service is compliant with UBC’s Information Security Standards. | ❌ | ✅ | ❌ |
FAQs
Get Help
For support or more information about this service, please submit a submit a Cybersecurity Services Support Request through the UBC Self-Service Portal.
Include the following information when requesting support:
- Your CWL username
- SSH client used
- Command used to connect
- Error message received
- Date and time of the issue