Differences
This shows you the differences between the selected revisions of the page.
2025-05-28 | 2025-05-29 (current) | ||
Rewrote the entire article in simpler, beginner-friendly language. Added detailed explanations to help new users understand SSH key pairs, what each key does, and who uses them. Kept the original structure and content but expanded explanations, added security tips, and clarified technical terms using easy words. (103.57.224.183) (hidden) (untrusted) | Restored revision 1742299451. Undoing revisions 1748454814, 1748455028, 1748455408. (martin) (hidden) | ||
Line 1: | Line 1: | ||
====== Understanding SSH Key Pairs ====== | ====== Understanding SSH Key Pairs ====== | ||
+ | In every SSH/SFTP connection, there are four keys (or two key pairs) involved. This article explains the difference between them and what keys an %%SFTP%% client user needs to care about. | ||
- | When you connect to a server using SSH or SFTP (for example, using Git or WinSCP), there are *four* important keys being used. These are called “key pairs” — which means two keys that work together. | + | The %%SSH%% employs public key cryptography. A [[wp>Public-key_cryptography|public-key cryptography]], also known as asymmetric cryptography, is a class of cryptographic algorithms which requires two separate keys, one of which is secret (or private) and one of which is public.((&wikipedia_ref(Public-key_cryptography|Public-key cryptography))) Together they are known as a key pair. In %%SSH%%, the public key cryptography is used in both directions (client to server and server to client), so two key pairs are used. One key pair is known as a host (server) key, and the other is a user (client) key. |
- | This guide explains each of these keys in simple terms and helps you understand which ones you, as a user, need to know about. | + | ===== User Private Key ===== |
+ | A //user private key// is a key kept secret by the %%SSH%% user on their client machine. The user must never reveal the private key to anyone, including the server (server administrator), not to compromise their identity. | ||
- | ==== 🔐 What is Public Key Cryptography? ==== | + | To protect the private key, it should be generated locally on a user's machine (e.g. using [[ui_puttygen|PuTTYgen]]) and stored encrypted by a passphrase. The passphrase should be long enough (that's why it's called passphrase, not password) to withstand a [[wp>Brute-force_attack|brute-force attack]] for a reasonably long time, in case an attacker obtains the private key file. |
+ | Different file formats are used to store private keys. WinSCP supports PuTTY format, with the ''.ppk'' extension. | ||
- | SSH uses something called [[wp>Public-key_cryptography|public key cryptography]], also known as *asymmetric cryptography*. ((&wikipedia_ref(Public-key_cryptography|Public-key cryptography))) It’s a type of security system that works with **two different keys**: | + | ===== User Public Key ===== |
+ | A user public key is a counterpart to //user private key//. They are generated at the same time. The //user public key// can be safely revealed to anyone, without compromising user identity. | ||
- | - A **private key**: This must always be kept secret. | + | To allow user authorization on a server, the user039;s public key is registered on the server. In the most widespread %%SSH%% server implementation, the OpenSSH, file ''~/.ssh/authorized_keys'' is used for that. |
- | - A **public key**: This can be shared with others. | + | |
- | These two keys are created as a **pair** and work together. | + | //Learn more about [[public_key|public key authentication]] in general and how to [[guide_public_key|setup authentication with public keys]].// |
- | Here’s how it works: | + | ===== Host Private Key ===== |
- | - One person locks the message with the public key. | + | A //host private key// is generated when the %%SSH%% server is set up. It is safely stored in a location that should be accessible by a server administrator only. The user connecting to the %%SSH%% server does not need to care about //host private key// in general. |
- | - Only the matching private key can unlock it. | + | |
- | This means you can safely share the public key, and people can send you messages that only *you* can unlock using your private key. | + | ===== Host Public Key ===== |
- | + | A //host public key// is a counterpart to //host private key//. They are generated at the same time. The //host public key// can be safely revealed to anyone, without compromising the host's identity. | |
- | In SSH, this key system is used in *both directions*: | + | |
- | 1. The **user** (you) proves their identity to the server. | + | |
- | 2. The **server** proves it is real to the user. | + | |
- | + | ||
- | So there are **two pairs of keys** involved: | + | |
- | - One key pair belongs to the **server** (called a host key). | + | |
- | - One key pair belongs to the **user** (you). | + | |
- | + | ||
- | Let’s look at each of the four keys. | + | |
- | + | ||
- | ===== 🧍♂️ User Private Key ===== | + | |
- | + | ||
- | This is your personal secret key. It is saved on your computer and should **never be shared** with anyone — not even with the server admin. This key proves **you are really you** when you connect to the server. | + | |
- | + | ||
- | - You create the private key on your own computer using a tool like [[ui_puttygen|PuTTYgen]]. | + | |
- | - It should be **protected by a passphrase** — which is like a very strong password. | + | |
- | - The passphrase makes the key safer, so even if someone steals your private key file, they still can’t use it. | + | |
- | - Make sure your passphrase is long and hard to guess (this is why it’s called a *passphrase*, not just a password). | + | |
- | + | ||
- | There are different formats for private key files. If you're using **WinSCP**, it uses the PuTTY format, which ends in `.ppk`. | + | |
- | + | ||
- | 🔒 **Remember**: Never share your private key. Keep it safe and protected. | + | |
- | + | ||
- | + | ||
- | ===== 📢 User Public Key ===== | + | |
- | + | ||
- | This is the matching key to your private key. It’s created at the same time. Unlike the private key, this **can be shared with others** — it’s safe to send your public key to a server. | + | |
- | + | ||
- | When you want to log into a server using SSH or SFTP: | + | |
- | - The server needs your **public key** to recognize you. | + | |
- | - You (the user) send the public key to the server admin. | + | |
- | - The server stores your public key in a file called `~/.ssh/authorized_keys`. | + | |
- | + | ||
- | This lets the server say: “Yes, this person’s private key matches the public key I have — they are allowed to connect.” | + | |
- | + | ||
- | This system is called *public key authentication*. It lets you log in without entering your password every time, and it's much more secure than using passwords. | + | |
- | + | ||
- | >> Want to learn more? Read about [[public_key|public key authentication]] and how to [[guide_public_key|set it up properly]]. | + | |
- | + | ||
- | + | ||
- | ===== 🖥️ Host Private Key ===== | + | |
- | + | ||
- | This private key belongs to the **server** (not you). | + | |
- | + | ||
- | - It’s created when the server is first set up. | + | |
- | - It is stored in a protected folder on the server. | + | |
- | - Only the **server admin** should have access to this key. | + | |
- | + | ||
- | As a user, you do **not** need to worry about the host private key. You will never use or see it. | + | |
- | + | ||
- | The server uses it to prove its identity to your computer, just like you use your private key to prove your identity to the server. | + | |
- | + | ||
- | + | ||
- | ===== 🌐 Host Public Key ===== | + | |
- | + | ||
- | This is the public version of the server’s private key. | + | |
- | + | ||
- | - It is safe for you (the user) to see and store. | + | |
- | - It helps your computer verify that it is connecting to the **correct server**. | + | |
- | + | ||
- | When you connect to a server for the first time, your SSH tool (like Git Bash, VS Code terminal, or WinSCP) will show you the server’s **host public key**. This is your chance to **make sure the key is correct**. | + | |
- | + | ||
- | Usually: | + | |
- | - You get this key from the server admin or website in advance. | + | |
- | - You compare the key you see with the key you were given. | + | |
- | - If it matches, you can save and trust the connection. | + | |
- | + | ||
- | Once your system saves the host public key, it will automatically check it every time you connect again. If the key ever changes, your computer will show a warning — this could mean the server changed, or it might be a sign of a security issue (like someone trying to trick you). | + | |
- | + | ||
- | So: | + | |
- | - First connection: You approve the host public key. | + | |
- | - Next connections: It’s auto-checked. | + | |
- | - If it changes: You get a warning. | + | |
- | + | ||
- | You can read more about this here: [[faq_hostkey|Host key FAQs]] and how to [[ssh_verifying_the_host_key|verify and accept a server key]]. | + | |
- | + | ||
- | + | ||
- | ===== ✅ Summary (in simple points) ===== | + | |
- | + | ||
- | - SSH uses **two key pairs**: one for you (the user), and one for the server. | + | |
- | - Each pair has a **private key** (kept secret) and a **public key** (can be shared). | + | |
- | - Your **private key** stays on your computer, locked with a strong passphrase. | + | |
- | - Your **public key** is given to the server so you can log in securely. | + | |
- | - The server’s **host key** helps your computer know it’s connecting to the right server. | + | |
- | + | ||
- | Always keep your private key safe. Never share it. If you're not sure about a key, **ask** before you accept it. | + | |
+ | To allow authorizing the host to the user, the user should be [[faq_hostkey|provided with host public key in advance]], before connecting. The client application typically prompts the user with //host public key// on the first connection to allow the user to [[ssh_verifying_the_host_key|verify/authorize the key]]. The //host public key// is then saved and verified automatically on further connections. The client application warns the user if the host key changes. | ||