L49
SSH versus Telnet and server identity
Cram this first — memory hook
Door 22 has two keys; door 23 has an open window.
Exam trap
Encrypting a connection to an attacker does not make the endpoint trustworthy. Server identity verification is part of secure access.
The slide facts
Secure Shell supports host keys and client authentication methods. Telnet supplies remote terminal functionality but sends traffic without 's protection.
If you have time — extra
Secure Shell (), normally Transmission Control Protocol () 22, provides encrypted remote access and protects the server/client authentication exchange. A host key identifies the server; a user's key pair can authenticate the client. These are different roles. Telnet, normally 23, provides remote terminal communication without comparable encryption, making ordinary credentials/content observable to someone able to inspect the path. An client should not blindly accept an unexpected host-key change: it may reflect a legitimate rebuild, but also impersonation or interception. Verify through a trusted channel. Public-key authentication does not mean sending your private key to the server; the client proves possession. Appropriate access rules should restrict management connections to authorized sources.
Walkthrough
Connect to the intended server, verify its host identity, authenticate the user by an approved method, perform authorized administration, and retain relevant logs. Prefer secure management protocols.