nerdexam
LPI

117-102 · Question #743

When generating new authentication keys with SSH for a user, where should the private key be kept?

The correct answer is A. On any trusted system from which the user will login. See the full explanation below for the reasoning.

Question

When generating new authentication keys with SSH for a user, where should the private key be kept?

Options

  • AOn any trusted system from which the user will login.
  • BOn a CD-ROM or USB stick.
  • CPrinted and kept in a secure place.
  • DOnly on the computer where the key was created.
  • ESSH does not use private keys.

How the community answered

(30 responses)
  • A
    80% (24)
  • B
    10% (3)
  • D
    3% (1)
  • E
    7% (2)

Community Discussion

6
Marit C.Marit C.Dec 13, 2025

The correct answer is A. The private key is the credential that the SSH client presents during the authentication handshake, so it must reside on whatever system the user is initiating the connection from, meaning the client side. If you lock it to only the machine where it was generated (option D), you have broken portability and the user cannot authenticate from any other workstation, which defeats the practical value of key-based auth entirely. Options B and C describe storage for backup or archival purposes, not active use, and the SSH daemon on the remote end only ever sees the public key sitting in authorized_keys, it never touches the private key at all, which also rules out E as nonsense. The mental model to carry into the exam is simple: public key lives on the server, private key travels with the user to every trusted client they work from.

27
Viktor S.Viktor S.Dec 13, 2025

Solid breakdown, but "travels with the user to every trusted client" is worth tightening since copying your private key to multiple machines multiplies your exposure surface, and the more defensible practice for real environments is a hardware token or SSH agent forwarding so the key material itself stays in one place.

0
Samuel O.Samuel O.Nov 30, 2025

The private key needs to follow the user, not the server, so wherever they authenticate from that machine needs to have the private key on it, which is exactly why A is correct. But here is what I always ask people who are new to this: what stops someone from just copying that private key onto every machine they use, and why might that be a problem even if each of those machines is "trusted"?

3
Nina C.Nina C.Dec 3, 2025

Copying it everywhere turns one private key into many potential points of failure, so if any one of those "trusted" machines gets compromised or lost, the attacker now has a key that works everywhere, and you have no clean way to revoke just that one copy without re-keying the whole setup.

0
Viktor S.Viktor S.Dec 3, 2025

A, because you own the private key and take it wherever you authenticate from. Sat my 102 back when I still had hair, hit this exact question, nearly picked D out of paranoia, then remembered the point is access from any machine YOU trust, not jail it to one box.

3
Nina C.Nina C.Nov 27, 2025

I got this one wrong the first time I practiced it because I kept thinking "private key should stay put," but then I second-guessed myself on the actual exam and almost picked D. What clicked for me was remembering that the private key belongs to the user, not to a single machine, so it needs to follow the user to any trusted computer they sit down at to authenticate. The whole point is that the private key is the credential that proves who you are, so if you log in from your work laptop and your home desktop, the private key needs to be on both of those machines. On the exam I went back to A after reminding myself that locking it to only the machine where it was created would break the whole workflow for anyone who uses more than one device.

0
Full 117-102 Practice