Connect

Other terminal protocols

Understand when Mosh or Telnet is appropriate, and why protocol support depends on the route.

2 min read User guide

Choose the server's protocol

SSH is the normal starting point for a secure terminal. Some installations also expose alternate protocols. Selecting one changes the requirements on the server and network; it does not convert an SSH-only server into another kind of service.

Use an alternate protocol only when your release offers it and the administrator approves it. Keep a working SSH profile while testing another method.

Mosh and changing networks

Mosh can help a terminal tolerate changing network addresses and interruptions. It requires compatible remote support and a route that carries the necessary traffic. A successful SSH handshake does not prove the subsequent Mosh traffic can cross a firewall or relay.

  1. Confirm that the remote machine has the required Mosh support.
  2. Confirm that the network and route allow its traffic.
  3. Select Mosh where available and connect with the approved authentication.
  4. Check the actual session status before assuming roaming protection is active.

A WebSocket-only self-hosted kit is not automatically a datagram relay. Check your particular kit and client for compatibility.

Telnet is not encrypted

Telnet sends traffic and credentials without SSH's encryption. Treat it as an isolated-network compatibility tool, not an alternative for internet administration. OmniTerm can restrict it to isolated environments.

Do not send a reusable password over an untrusted Telnet connection. For graphical sessions, use the separate remote desktop guide; terminal protocol settings do not automatically configure RDP or VNC.

Features vary by release, platform and connection route. Check availability before planning your setup.

Search the guides

Search runs in your browser.

Your search stays here. No account or external search service.