SSH setup

Telnety speaks SSH natively through russh. That gives you async I/O, modern algorithms, and a clean key-exchange path without shelling out to OpenSSH. This guide covers the everyday SSH workflows you'll use most: keys, agent, jump hosts, host-key trust, and port forwarding.

Authentication methods

Pick the method that matches your environment. You can change it later from the host edit dialog without re-creating the entry.

• Password — works everywhere but is the weakest. Store passwords in the encrypted vault rather than typing them on every connect.
• SSH key — the default for most modern setups. Telnety supports Ed25519 (recommended), RSA (2048/4096), and ECDSA (P-256/P-384/P-521).
• SSH agent — let the built-in agent (or your system agent) hold the keys in memory. Keys never touch disk in plaintext.
• Keyboard-interactive (TOTP, OTP) — for hosts that prompt for a one-time code after the key check.

Generate Ed25519 keys

Ed25519 is the right default in 2026: short, fast, and resistant to most weak-RNG problems that have bitten RSA over the years. Telnety can generate one for you without leaving the app.

1. Open Settings → SSH Keys, or hit Ctrl+K and search for “generate ssh key”.
2. Pick Ed25519 as the algorithm. Telnety pre-fills the comment with user@hostname; change it to something meaningful (project, machine, year).
3. Set a passphrase. Passphrase-protected keys can still be stored in the vault, so you only type it once per workspace unlock.
4. Click Generate. Telnety writes the key pair to your user keys directory and immediately offers to copy the public key to your clipboard so you can paste it into an authorised_keys file or a hosting dashboard.

# macOS / Linux default
~/.ssh/id_ed25519
~/.ssh/id_ed25519.pub

# Windows default
%USERPROFILE%\.ssh\id_ed25519
%USERPROFILE%\.ssh\id_ed25519.pub

The built-in SSH agent

Telnety bundles a small SSH agent that runs alongside the app. It accepts the standard protocol on a local Unix socket (or named pipe on Windows). Keys you add to the agent unlock once and stay available for every connection in the session, then disappear when you close the app.

# macOS / Linux — set the socket Telnety publishes
export SSH_AUTH_SOCK="$(telnety agent socket)"
ssh-add ~/.ssh/id_ed25519

# Windows PowerShell — set the named pipe
$env:SSH_AUTH_SOCK = telnety agent socket
ssh-add $env:USERPROFILE\.ssh\id_ed25519

Agent forwarding

Agent forwarding lets you authenticate from a remote shell back to a third host without copying private keys around. Enable it per host on the Authentication tab, or globally in Settings → SSH.

Telnety scopes forwarded agents to the specific connection so a compromised bastion only sees the keys actively being used during that session. The forward is torn down the instant the tab closes.

Jump host chains

Reach hosts that aren't directly routable by chaining through a bastion. Telnety supports arbitrary multi-hop chains via SSH's direct-tcpip channel, the same mechanism OpenSSH uses for -J and ProxyJump.

Final host:  app-server-01.internal     port 22
Jump host:   bastion.example.com         port 22
Local user:  ops
Auth path:   reuse the same SSH key for both hops

Telnety renders the chain in the connection inspector so you always know which hop a prompt is coming from. Each hop has its own host-key entry and TOFU prompt.

Host-key TOFU

Trust-on-first-use (TOFU) is the only sane default for SSH host keys: accept the first fingerprint you see for a host, refuse anything different later. Telnety stores host keys per host entry, surfaces the fingerprint in plain SHA-256 form, and refuses to silently accept a changed key.

The authenticity of host 'example.com (203.0.113.7)' cannot be established.
ED25519 key fingerprint is
  SHA256:bUq3KH8tZ6QKgN9X4Yj4FfY2k2Q3lH7l5q1V7sQ3v8I

Are you sure you want to continue connecting? [yes/no/show all]

If a host key changes (legitimately, after a server rebuild) you can clear the stored fingerprint from the host's detail panel and accept the new one on the next connect.

Port forwarding

Telnety supports both local (-L) and remote (-R) forwarding, configured per host. Forwards survive reconnects when Auto-reconnect is enabled.

# Local forward: open Postgres on the bastion through to my laptop
local  127.0.0.1:5432  ->  10.0.0.5:5432

# Remote forward: expose my local web app to the dev box
remote 0.0.0.0:8080   ->  127.0.0.1:3000

# Dynamic SOCKS proxy
dynamic 127.0.0.1:1080

Reading ~/.ssh/config

Telnety reads your existing ~/.ssh/config file on startup so hosts you already have configured for OpenSSH show up in a dedicated SSH config group in the sidebar. Telnety treats the file as read-only by default; saving an edit in Telnety produces a new host entry rather than rewriting your config.

Session recording

Enable session recording per host or globally. Every byte of the terminal stream is captured in Asciicast v2 format and stored locally. Play recordings back inside Telnety or share them as asciinema links.

• Capture happens before terminal rendering, so colour codes and cursor moves are faithfully reproduced.
• Recordings live in the workspace database; nothing is uploaded unless you explicitly export.
• You can pause and resume recording with Ctrl+Alt+R.

Troubleshooting

Telnety logs each SSH transaction to a per-session log that you can open from the Sessions tab. The most useful symptoms-to-fixes mapping:

• Permission denied (publickey) — the server doesn't accept the key you offered. Check that the public key is in ~/.ssh/authorized_keys on the server and that the file is mode 600 owned by the right user.
• Connection refused — the SSH daemon isn't listening on the port you specified, or a firewall is blocking it. Use the built-in Port scan tool to confirm.
• Host key changed — never accept blindly. Verify the new fingerprint out of band (cloud console, /etc/ssh logs) before clearing the stored key.
• Hangs at “Authentication” — usually keyboard-interactive prompting for a TOTP. Toggle the prompt mode in the auth tab.