This is aimed at people using SSH in their daily work - it does not deal with details of the SSH protocol itself.
pubkey can also check signatures, but that's less important in ssh use.
This enables one-way secure communication - others can now send data to you that
can not be read or changed on the way to you. That's great, but you want to communicate bi-directionally...
Now both parties (client and server) have a way to receive encrypted messages, and as mentionend use this to share a session secret (for efficiency and speed) for running sessions.
Under the hood, SSH will use temporary pub/priv keys to establish the connection, then switch to symmetric encryption where the shared secret is randomly generated between the
SSH parties and transmitted securely through the magic of pub/priv crypto.
you will have seen a message popping up when you connect to a new host for the first time, displaying some form of
Another message you might have seen is this one:
In both cases, you should think about what is going on. First case is pretty normal, you're connecting to a host that you have no previous information on. It's usually okay to say yes here. For the extra paranoid, verify the host key fingerprint through a secure side channel (phone? DNS? photo? etc...) before continuing the connection.
Don't follow the second message blindly say yes, think about *why* the host key might have changed. Did you recently do a dist-upgrade, did someone reinstall the machine without backing up/restoring the host keys, or was there a major breaking change with ssh during a system upgrade run? In any case, be vigilant.
If you said "yes" on the prior page, how does your local ssh client actually save this information? There are two spaces, with the global one usually not being used.
(this is what happens when you answer "yes" on the first connection to a host and )
This makes some deleting entries a lot harder than before, and it might break some tab-completion magic that might use the known_hosts file
You might want to roll out the known_hosts centrally.
Right, that's the basic how. Let's get to some things that make your life so much easier, yet that are often misunderstood.
The most widely used yet often misunderstood features of SSH. This is why you are here.
One of the core failures of the whole SSH ecosystem is the default naming convention for private/public keys. Accidentally cat'ing your private key is way too easy.
rsa, dsa, ed25519 are different variants/types of encryption. When in doubt, use RSA.
(I would always go with ED25519 for modern deployments, though it might not work on systems that are older than 2020ish)
Securing your private key with a passphrase (which just means "long password") is a good precaution, it means somebody that gets access to your private key cannot immediately use it.
Okay, now you have your key, and you can give the public side of it to others. If others want to securely encrypt something that **only** you can decrypt, they use your **public** key to encrypt. You then use your **private** key to decrypt.
In order to use this for authentication instead of a password, the SSH server will essentially encrypt something with your public key and ask you to send the decrypted text back (to prove that you are indeed in posession of the private key part)
Yes, this feels identical to logging in with a password, except I was encouraged to make my passphrase longer and more annoying to type. Great job, you've made using ssh more annoying.
Should probably more accurately be called the SSH private key cache. It's well integrated into openssh, and normal ssh connection attempts will try to use your local ssh agent automatically.
On macos, you can use the system keychain to store the passphrase, where they will live together with all the other saved passwords, protected by a master password. It's ```UseKeychain yes
``` in your .ssh/config, and I would recommend to use that if you're on a mac.
On windows, putty has "pageant" to serve as private key cache, it works identically, though by default does not set a lifetime (you do need to re-enter passphrase after rebooting)
This is a must-have if you're serious about using key-based auth. You can get by with using keys without passphrase, but please don't, it carries a heavy price in terms of identity theft and potential damage to your reputation. As a sidenote, with more and more machines ending up in an MDM (mobile device management) "friendly rootkit" scenario, your private keys, passphrases and logins etc are essentially all compromised (to your MDM admins), making (digital) identity inside your company all but meaningless, but that is a topic for another talk... or hit me up later, I will talk at length about the problems I see with MDM :)
you have essentially compromised your keys to every admin of the intermediary system. Be very, very careful where you agent forward to. Come visit my advanced SSH workshop to learn a better way.