YanoSecAn authorized remote lab gives you an account name, a host and a port. Before connecting, identify each part of the command and the evidence that this is the intended server. Correct syntax alone cannot supply authorization or verify its identity.
SSH, Secure Shell, is a protocol and tool family for encrypted remote sessions. A host is a computer reached through the network. A port number helps select the service on that host. This lesson only reads fictional endpoint labels; it makes no connection.
Before you begin
- Recommended first
- Install Ubuntu LTS and open a terminal, Where practice is allowed, An editor that works under pressure
- Estimated time
- 15 min reading, 15 min activity. Setup and optional practice may take longer.
- Where you work
- Use Bash in your owned Ubuntu practice environment as an ordinary user. The supplied text files use UTF-8, a text encoding; where shown, LC_ALL=C requests consistent text ordering. Work only under your own new ~/yanosec-lab directory, never a host share or personal/system file. Refuse an existing exercise destination rather than overwriting it. No account, paid platform, or remote target is required. Optional extensions take about 10–15 minutes and are not part of the time above. A virtual machine is optional. You can also finish the reasoning from the printed evidence.
- Without a lab
- The page supplies the files, source and text records needed for the activity. Without a shell, follow the numbered steps on paper, label each result as predicted, and use the separate evidence supplied by the question. Running commands can wait until your lab is available. Reading works without JavaScript. Answer checking needs JavaScript and a secure context, such as HTTPS; saving a correct result also needs usable browser storage. Missing tools, managed or mobile hosts, or a deferred guest setup never require buying a service. Keep owned lab files for review; do not use broad deletion.
After this lesson you can:
- Identify the username, endpoint label and port in an SSH syntax card.
- Distinguish a server host key from a user authentication key.
- Write a private connection plan without contacting a fictional or unapproved target.
01Example
This syntax-only worked example uses port 2202. -p introduces the port argument, and trainee@example-label combines account and host label. The label is fictional: do not resolve or contact it. The guided activity uses different values.
Syntax to read, not execute:
ssh -p 2202 trainee@example-label
Command: ssh
Port option/value: -p 2202
Remote username: trainee
Host label: example-label
No real endpoint, fingerprint or password is supplied.02Authenticate the server as well as the account
A server host key is a cryptographic key used to identify the server. A fingerprint is a compact representation of a public key that you can compare with a trusted reference. Before accepting a new host key, compare it with the fingerprint in the authorized owner's trusted instructions.
User authentication checks the account login. It may use a password or a user public/private key pair. A public key can be registered with the authorized operator; the private key must remain private. These user keys serve a different role from the server's host key.
A first connection can present a key without independently proving it belongs to your intended server. A changed-key warning can have several causes and needs investigation. Pause and verify through a trusted channel instead of disabling checking or deleting the warning evidence.
After a later authorized login, commands operate in the remote account's environment, with its own working directory and permissions. exit normally ends an ordinary remote shell. The syntax activity here starts no session and needs no remote cleanup. Never include passwords or private keys in a help draft.
Parse account, host and port without converting missing server-verification evidence into a trusted connection.Model. A teaching model drawn by hand. It shows the idea, not real tool output.
Read the full explanation below.
Fictional syntax, not a live endpoint
ssh -p 2202 trainee@example-label
Missing identity evidence
Trusted server fingerprint: not supplied
Password: not supplied
-p 2202 specifies the destination port.
Syntax only; no connection is made.
-p 2202 specifies the destination port.
Follow the explanation
- -p 2202 specifies the destination port.
- trainee names the remote account; example-label is a fictional host label.
- Server host-key verification and user authentication are distinct checks.
Read every state and value
1. -p 2202 specifies the destination port.
- Selected parts
- Command · Destination port
- Explanation
- endpoint
2. trainee names the remote account; example-label is a fictional host label.
- Selected parts
- Remote account · Fictional host label
- Explanation
- identity
3. Server host-key verification and user authentication are distinct checks.
- Selected parts
- No trusted fingerprint · No password
- Explanation
- verify
03Try the endpoint note
The worked syntax uses port 2202. The activity card uses learner, assigned-host and port 2222. Write a new command from those supplied fields, label its parts, and leave all real connection details pending. Do not execute a fictional label.
The checklist supplies the remaining reasoning: identify permission, allowed actions and time, actual endpoint, and a trusted fingerprint before any future connection. Then separate server verification from account authentication. A browser and notes provide every fact needed for this task.
Read endpoint syntax without making a connection
-p introduces a port number. user@host combines the account and host
label. A host key identifies the server; a user key helps authenticate
the account. Compare the server fingerprint with a trusted reference
before a later authorized connection. Syntax cannot supply permission.
These names are labels only, not hosts to resolve or connect to.
Worked syntax: ssh -p 2202 trainee@example-label
Activity card: username learner; endpoint assigned-host; port 2222;
host key must match fingerprint supplied by authorized owner separately.
Build a connection note; do not run the fictional endpoint.
Question syntax: ssh -p 2220 learner@lab-host
Which number selects the port? Enter digits only.
Public key may be given to the authorized account operator; private key
must stay private. Host key identifies server; user key authenticates user.
No connection/password/key data is supplied or actual session claimed.
- Read the Activity card: learner, assigned-host and port 2222. Write a syntax-only command and label its parts. Expected: ssh -p 2222 learner@assigned-host; do not execute it.
- Add fields for permission, actual endpoint, allowed actions/time, and trusted host-key fingerprint. Leave unknown fields pending instead of inventing credentials or an address.
- Separate server host-key verification from user authentication. Explain why the public key can be registered with an authorized operator while the private key is not posted or sent in a help draft.
- Write a stop rule for absent authorization or an unexplained fingerprint change. Expected: pause and verify with the authorized owner through a trusted channel, not bypass the check.
- Finish the private note. No connection was made, account created, key generated or remote cleanup requested. The no-install route uses exactly the same evidence.
04Optional challenge
Allow about ten extra minutes. A connection card names a nondefault port. Explain why omitting -p can select a different port and therefore fail or reach another service. List the trusted identity evidence you would need before accepting a server key; do not scan or connect to answer.
05Fresh cases for the checks
Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.
SSH card A: fictional syntax to read, never executeOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
ssh -p 2246 rhea@training-label
training-label is a fictional label, not a real endpoint.
No permission, trusted fingerprint, password or private key is supplied by this syntax.
SSH card B: separate diagnostic reportsOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Report H: the client reports that the presented server host key differs from the saved one.
Report U: after a separately trusted server identity check, the service rejects the supplied account login.
Report P: a learner includes their private user authentication key in a public help draft.
These are different fictional cases, not steps in one connection.
None of the reports gives permission to try another account or bypass verification.
SSH card C: a private plan with missing evidenceOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
A future lab owner has provided explicit permission, the actual endpoint, allowed actions/time and an account name.
The private plan still has no trusted server host-key fingerprint.
A learner proposes accepting any displayed key because they possess a user authentication key pair.
No connection is being made in this exercise.
SSH card D: a new syntax-only noteOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.
Remote username: robin
Fictional host label: rehearsal-label
Port: 2294
Write only the form ssh -p PORT USER@HOST, with one space between words.
Do not execute, resolve or contact the fictional label.
06Review a private connection plan
Optional self-check: write a private plan for a future authorized SSH lab without connecting. Use placeholders for real details and leave unknown fields pending.
Review your plan: include permission, allowed actions/time, actual endpoint, account and port; require a trusted server fingerprint comparison; distinguish that check from account authentication; keep passwords and private keys out of help drafts; and pause for missing permission or unexplained key changes. State that this exercise made no connection. This plan is self-reviewed.
07Common mistakes
If you confuse a password or username with the port, follow the option/argument pairing and user@host syntax. Do not copy fictional labels into a real connection attempt.
If a future authorized connection fails, distinguish endpoint, service availability, host identity and account authentication. Record a redacted real error rather than trying peers or other hosts.
If a host-key mismatch appears in later live work, stop and verify the change; do not disable checking or erase known-host evidence to make the warning disappear. No connection transcript was observed here.
References
- Ubuntu 24.04 packaged manual: ssh(1)
Use the named command and option sections. This manual describes Ubuntu 24.04 packages; your installed version can differ. The lesson supplies the facts needed for its activity.
- OpenSSH: Manual Pages
Primary project entry point for SSH client/configuration and key terminology. Linked development manuals may differ from the installed Ubuntu client; use the help installed on your own machine.