The remote terminal
A remote shell is an application protocol, not a secure channel by itself.
A terminal client sends keystrokes and receives characters, prompts, status, and terminal-control information from a remote service. TCP provides the ordered byte stream; the application protocol defines how the session starts, how terminal behavior is negotiated, and how identity is trusted.
Historical protocol
Telnet carries a negotiated virtual terminal over TCP port 23.
Telnet uses the Network Virtual Terminal model so clients and servers can agree on terminal characteristics across different systems. Control commands are introduced with the IAC (Interpret As Command) byte, allowing option negotiation such as echo behavior, terminal type, and binary mode.
Telnet does not provide confidentiality or strong peer authentication. Usernames, passwords, commands, and output can be observed or altered by an attacker who can inspect the path. It is therefore unsuitable for ordinary administration across an untrusted network.
TCP/23
The standard server port for a Telnet service.
NVT
A common terminal representation for interoperability.
IAC
Escapes a byte to signal Telnet commands and option negotiation.
Cleartext
The session has no built-in encryption or integrity protection.
Unix heritage
Rlogin assumes a trusted Unix environment.
Rlogin, historically associated with BSD Unix, opens a remote login session over TCP port 513. The client communicates local and remote usernames, terminal information, and control data before carrying the interactive session. Related BSD tools such as rsh used similar trust assumptions for remote commands.
Host-based trust mechanisms such as .rhosts and host equivalence could let a server accept a login based on the claimed or resolved client identity. Those assumptions are fragile: address spoofing, DNS mistakes, compromised hosts, and untrusted networks can turn convenience into unauthorized access. Rlogin also lacks encryption and robust cryptographic peer authentication.
Modern replacement
SSH protects the session before it carries the shell.
SSH uses TCP port 22 and begins with protocol-version exchange, algorithm negotiation, a key exchange, and server-host authentication. After the session keys are established, encrypted and integrity-protected channels can carry an interactive shell, commands, port forwarding, or subsystems such as SFTP.
The client should verify the server host key, commonly through a known-hosts database or another trusted enrollment process. User authentication can then use a password, public key, certificates, or other configured mechanisms. Encryption protects content in transit, but it does not make a compromised endpoint trustworthy.
TCP/22
The conventional SSH service port.
Host key
Lets the client detect an unexpected server identity or changed key.
Key exchange
Establishes shared session keys without sending them as plaintext.
Channels
Carry shells, commands, forwarding, and subsystems over one protected connection.
Compare the promises
The port identifies a service; the security model determines whether to trust it.
Telnet
TCP/23, virtual terminal and option negotiation, no encryption, weak or external authentication.
Rlogin
TCP/513, Unix remote login, host-based trust, no encryption, fragile identity assumptions.
SSH
TCP/22, negotiated cryptography, verified host keys, authenticated and integrity-protected channels.
Evidence
Check the listening service, handshake, host identity, authentication method, and protected channel.
Mini investigation
Inspect a remote-access clue
Select the observation and identify the strongest next check.
The SSH client has evidence that the server identity differs from its stored record.
Verify the server and host-key change through a trusted channel before accepting it.
Knowledge check
Test your remote-access model
Answer eight questions.