Validate remote access to a modern host using SSH with host key verification, then confirm legacy port reachability using a Telnet session. Exit each session cleanly to keep operator behavior predictable during troubleshooting.
You are working remotely and need to validate access to two
services on the same host: secure administration via
ssh and a legacy service reachable on TCP port
23. You must confirm network reachability,
handle the initial SSH host key prompt correctly, exit cleanly
from the remote shell, then perform a Telnet connection test
to confirm that the legacy port is accepting connections.
SSH is the standard for secure remote administration. Telnet is plaintext and should not be used for sensitive work, but it still appears in legacy environments where the practical use case is confirming basic TCP reachability.
192.168.0.42 as user
admin and accept the host key prompt.
23.
~/.ssh/known_hosts.
ssh admin@192.168.0.42
On first connection, SSH prompts you to confirm the host key
fingerprint. Accepting the prompt adds the host to your
known_hosts file and protects you from silent
man-in-the-middle changes later.
The authenticity of host '192.168.0.42' can't be established.
ECDSA key fingerprint is SHA256:examplekey.
Are you sure you want to continue connecting (yes/no/[fingerprint])?
yes
Warning: Permanently added '192.168.0.42' (ECDSA) to the list of known hosts.
admin@192.168.0.42's password:
Welcome to remote server.If you did not expect a host key prompt for this system, stop and validate the fingerprint out-of-band before proceeding.
exitUse a clean exit to keep your workflow predictable. This matters when you are jumping between multiple sessions and tracking which system you are actively operating on.
Connection closed.telnet 192.168.0.42 23Telnet is plaintext and not suitable for secure administration. In modern workflows, the common use is to confirm that a TCP port is reachable and a service is listening.
Trying 192.168.0.42...
Connected to 192.168.0.42.
Escape character is '^]'.
Welcome to Legacy Server.quitTerminate the Telnet session cleanly so the remote side closes the connection and you return to your local shell without ambiguity.
Connection closed by foreign host.Verify the username, credentials, and that the SSH service is reachable. If authentication is key-based or MFA-backed, a password prompt may indicate you are not using the expected auth path.
A changed host key can be legitimate (rebuild/rekey) or a
security issue. Validate the fingerprint before removing
entries from known_hosts.
The host is reachable, but nothing is listening on port
23 or a firewall is actively rejecting the
connection. Treat this as a service or policy signal, not a
routing signal.
Timeouts usually indicate filtering or routing problems. If SSH works but Telnet times out, a firewall rule is the most likely explanation.
If this is a lab host you will not reuse, remove the entry you
added to known_hosts to avoid stale fingerprints
during future exercises.
ssh-keygen -R 192.168.0.42
Your known_hosts entry for
192.168.0.42 is removed and future connections
behave as expected.
ssh <user>@<host>
: Connects to a remote system using the SSH protocol.
~/.ssh/known_hosts
: Stores trusted host keys after first connection.
exit
: Ends the current interactive shell session (used here to
terminate SSH cleanly).
telnet <host> <port>
: Opens a plaintext TCP session to a host/port for legacy
access or reachability testing.
23
: Default Telnet port.
quit
: Closes the current Telnet session and returns to the local
shell.
ssh-keygen -R <host>
: Removes all keys belonging to a host from
known_hosts.
-R
: Deletes matching host entries.