SSH Sessions with Jump Hosts and Sudo

An SSH session runs the system OpenSSH client on a PTY. The user's ~/.ssh/config, the key agent and known_hosts keep working. For each session the app writes a private ssh configuration with a block for every host on the way, then includes the user's own configuration.

Connect through parent turns the parent of a host into its jump host (ProxyJump), up the chain. In the pictures, every production host is reached through bastion.example.com. A host that needs a VPN brings it up before connecting, and the screen waits until it is connected.

Passwords are never in arguments or the environment. They go to ssh once, through the app's own SSH_ASKPASS helper, only when ssh asks for that user and host. Keys are paths, read each time. An .env file can name a key and carry the sudo password.

Sudo Login, a key button in the tab bar of every session, runs sudo su and types the password only once sudo asks for it. While the shell of a session is root (its prompt ends in #), its tab is tinted red and carries a red line. Active Sessions shows the user as root, and the log records an alert.

What it does

• System OpenSSH: your config, agent and known_hosts apply.
• Jump hosts through parents (ProxyJump), any depth.
• VPN brought up automatically before connecting.
• Secrets handed to ssh once, never on a command line.
• Sudo Login with the stored password; root sessions marked in red.
• Split opens another session of the same host.

How it behaves

• Each session's ssh folder is private to the user and removed when the session ends.
• Whatever else ssh asks, such as accepting a new host key, is asked in the terminal.
• Closing a root session asks first.

Why it matters

• Bastions, VPNs and sudo handled for you, safely.