Differences
This shows you the differences between the selected revisions of the page.
| 2025-05-28 | 2025-05-28 | ||
| Restored revision 1742299451. Undoing revisions 1748442396, 1748442415. (martin) (hidden) | ✅ Simplified Language: Rewrote all sections using easier and more beginner-friendly wording to help new users understand SSH keys without needing deep technical knowledge. 📌 Expanded Explanations: Added deeper and clearer explanations to each key (user/private/public, host/private/public), including: Why each key exists What each one is used for Who needs to care about it (user or server admin) 🧠 Step-by-Step Logic: Broke down the cryptography and connection process step by step, explaining how keys work together in SSH and SFTP. 🔒 Security Tips: Added practical tips about securing private keys and verifying server identity safely. 🧩 Maintained Original Structure: Kept the original BBCode format and all section headings (======, =====) intact — no content removed. 📎 Extra Context Links: Preserved all original wiki-style reference links and learning resources. ✅ New Final Summary Section: Added a quick bullet-point summary at the end to help reinforce and review the main ideas. (103.57.224.183) (hidden) (untrusted) | ||
| 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. | ||
| - | 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. | + | 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. |
| - | ===== User Private 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. |
| - | 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. | + | |
| - | 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. | + | ### 🔐 What is Public Key Cryptography? |
| - | ===== User Public Key ===== | + | 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**: |
| - | 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. | + | |
| - | To allow user authorization on a server, the user'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 **private key**: This must always be kept secret. |
| + | - A **public key**: This can be shared with others. | ||
| - | //Learn more about [[public_key|public key authentication]] in general and how to [[guide_public_key|setup authentication with public keys]].// | + | These two keys are created as a **pair** and work together. |
| - | ===== Host Private Key ===== | + | Here’s how it works: |
| - | 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. | + | - One person locks the message with the public key. |
| + | - Only the matching private key can unlock it. | ||
| - | ===== Host Public Key ===== | + | This means you can safely share the public key, and people can send you messages that only *you* can unlock using your private 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. | ||