Shell - SSH Configuration¶
SSH key management, keychain setup, and connection optimization.
Secure shell access is critical for development work. This section covers SSH setup with password-protected keys and keychain integration.
Generating SSH Keys¶
The frist step is to create an SSH key which is essential for many workflows, e.g. GitHub. You should always use a passphrase for security. When generating keys, use a strong password that you can remember:
1 | |
or better
1 | |
Important: When prompted for a passphrase, enter a strong password. This protects your key if it's ever compromised.
Configure SSH Keychain / Key agent¶
Use SSH keychain to securely store your SSH key passphrase in memory, eliminating the need to re-enter it for every SSH command. Install keychain this way
On Ubuntu/WSL:
1 | |
On macOS / RHEL flavours
1 2 | |
Then add to one of login shell configuration files (~/.profile or ~/.bash_profile or ~/.zprofile, but not ~/.bashrc or ~/.zshrc):
1 2 3 | |
Why use login shell config files?
The keychain setup should be in ~/.profile, ~/.bash_profile, or ~/.zprofile (not ~/.bashrc or ~/.zshrc) because:
- Login shell files run only on login shells (when you first log in)
- Interactive shell files (
.bashrc,.zshrc) run on every shell invocation, including non-interactive ones - This prevents redundant keychain initialization and improves shell startup performance
HPC Systems: Slurm Compatibility
The [ -z $SLURM_PTY_PORT ] check is critical for HPC users:
- What it does: Prevents keychain from running inside Slurm job steps
- Why: Slurm manages PTY (pseudo-terminal) resources for job steps, and keychain interferes with this
- Result: Your keychain works on login nodes but correctly disables within compute job allocations
Without this check, keychain initialization can cause issues or hangs when running jobs on Slurm clusters.
How It Works
- On your first SSH/Git command after login, you'll be prompted for your SSH key passphrase
- Enter your password - it's stored securely in your system keychain
- The passphrase persists in the keychain until you reboot your computer
- All subsequent SSH connections reuse the cached passphrase without prompting
- After reboot, you'll be prompted for your passphrase again on first use
This approach provides both security (your key is protected with a passphrase) and exceptional convenience (you only type your passphrase once per boot, not per session).
SSH Configuration for Jump Hosts¶
Note: You only need Jumphosts if you do not use VPN.
If you are using an ssh bastion or jump host in an enterprise/university environment, there are often no ssh keys allowed because of MFA autehntication needs. In that case you need to use the SSH controlmaster option if you do not want to enter your password all the time.
Create or edit ~/.ssh/config to simplify SSH connections and optimize performance:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | |
Key Configuration Options:
ControlPath: Directory for multiplexed connections (creates.ssh/controlmasters/dir)ControlMaster auto: Automatically reuse connectionsControlPersist 10m: Keep connections alive for 10 minutesServerAliveInterval 10: Send keepalive every 10 secondsServerAliveCountMax 3: Disconnect after 3 missed keepalivesProxyJump: Chain connections through jump hostDynamicForward: Enable SOCKS proxy through host
Setup multiplexing directory:
1 2 | |
Benefits:
- Faster connections: Reuses SSH connections, eliminates repeated authentication
- Reliable: Keepalive prevents timeouts on idle connections
- Secure: Jump host proxy keeps direct connections private
- Flexible: Works with any remote host configuration
Troubleshooting¶
SSH Key Permissions¶
Ensure proper permissions on your SSH keys - incorrect permissions can prevent SSH authentication:
1 2 3 | |
Explanation:
- ~/.ssh directory: 700 (rwx------) - only owner can access
- Private key: 600 (rw-------) - only owner can read/write
- Public key: 644 (rw-r--r--) - readable by others, writable only by owner
Keychain Not Working¶
If prompted repeatedly for your passphrase:
1 2 3 4 5 6 7 8 | |
SSH Connection Issues¶
- Test connections with
ssh -vfor verbose debugging - Check SSH config syntax:
ssh -T git@github.com - Verify remote host is accepting your key
- Ensure firewall isn't blocking port 22
SSH Security Best Practices¶
Keep SSH Keys Secure¶
- Never commit SSH keys to version control
- Never share your private key
- Always use strong passphrases
- Rotate keys periodically
- Use key files only for automated systems
SSH Agent Security¶
- Let keychain manage your passphrase
- Don't store unencrypted passphrases
- Lock your computer when stepping away
SSH Connection Best Practices¶
- Use SSH keys instead of passwords
- Keep SSH config clean and organized
- Monitor SSH access logs regularly
- Disable root login on remote servers