Feature Description
Add support for SSH proxy/jump hosts (bastion hosts) to allow WebSSH2 to connect to target servers through intermediate SSH servers. This is a critical feature for accessing servers in private networks or behind firewalls.
Background
PR #365 attempted to implement this feature but needs significant improvements and the codebase has evolved considerably since then. This issue captures the requirements for a proper implementation.
Use Cases
- Bastion Host Access: Connect to internal servers through a bastion/jump host
- Multi-hop Connections: Chain multiple SSH connections to reach deeply nested infrastructure
- Security Compliance: Many organizations require all SSH access to go through audited jump servers
- Cloud Infrastructure: Access private cloud instances through public-facing gateways
Proposed Implementation
Configuration Options
Support both global and per-connection proxy settings:
// Global proxy configuration in config.json
{
"ssh": {
"proxy": {
"enabled": false,
"type": "ssh|socks5|http", // Proxy type
"host": "proxy.example.com",
"port": 22,
"username": "proxyuser",
"auth": {
"type": "password|publickey|agent|keyboard-interactive",
"password": "...",
"privateKey": "/path/to/key",
"passphrase": "..."
},
"keepalive": 60000,
"readyTimeout": 20000
}
}
}
Per-Connection Proxy (via URL params or form)
/ssh/host/target.internal?proxy=bastion.example.com&proxyUser=admin
Multi-hop Support (ProxyJump style)
{
"proxy": {
"chain": [
{ "host": "jump1.example.com", "user": "user1" },
{ "host": "jump2.example.com", "user": "user2" }
]
}
}
Technical Requirements
Core Functionality
Authentication Methods
Advanced Features
Security Considerations
UI/UX Enhancements
Implementation Notes
From PR #365 Analysis
The original PR used a basic approach with ssh2.forwardOut() but had several issues:
- Hardcoded values and debug statements
- No password authentication support for proxy
- Memory management issues (unnecessary connection object creation)
- Synchronous file operations blocking event loop
- Limited error handling
Recommended Approach
- Create a separate
ProxyManager class to handle proxy connections
- Implement connection pooling for efficiency
- Use async/await patterns for better error handling
- Add comprehensive configuration validation
- Support OpenSSH config file format for familiarity
- Implement proper cleanup on disconnection
Testing Requirements
Documentation Needs
References
Success Criteria
- Users can connect to internal servers through bastion hosts
- Support for common enterprise proxy configurations
- Performance comparable to native SSH clients
- Clear error messages for connection issues
- Secure handling of proxy credentials
This feature request is based on the analysis of PR #365 and current architectural requirements for the WebSSH2 v2.0 rewrite.
Feature Description
Add support for SSH proxy/jump hosts (bastion hosts) to allow WebSSH2 to connect to target servers through intermediate SSH servers. This is a critical feature for accessing servers in private networks or behind firewalls.
Background
PR #365 attempted to implement this feature but needs significant improvements and the codebase has evolved considerably since then. This issue captures the requirements for a proper implementation.
Use Cases
Proposed Implementation
Configuration Options
Support both global and per-connection proxy settings:
Per-Connection Proxy (via URL params or form)
Multi-hop Support (ProxyJump style)
Technical Requirements
Core Functionality
forwardOut()methodAuthentication Methods
Advanced Features
Security Considerations
UI/UX Enhancements
Implementation Notes
From PR #365 Analysis
The original PR used a basic approach with
ssh2.forwardOut()but had several issues:Recommended Approach
ProxyManagerclass to handle proxy connectionsTesting Requirements
Documentation Needs
References
Success Criteria
This feature request is based on the analysis of PR #365 and current architectural requirements for the WebSSH2 v2.0 rewrite.