I want to setup an SFTP connection between my computer and a server.
I generated a pair of keys on my computer and wrote my public key in "authorized_keys" file on the server. I'm sure it works because when I try to connect from a computer that doesn't have my private key (I know, nobody else is supposed to have it), a password is asked.
According to this image, my server is Bob and my computer is Alice. When the server is sending a message, it uses my public key to encrypt it and I use my private key to decrypt it. But if I send a message to the server, it's not encrypted, is it? If it is, how is it encrypted?
From what I understood about asymmetrical cryptography, if I want to encrypt messages that I send, I have to generate a pair of keys on the server and put its public key in my computer's "authorized_keys" file, right?
How can I verify that the connection is secured in both way (sending and receiving)?
Thanks!
решение1
There are 2 major things happening in SSH connections:
Server Authentification & encryption
The server sends you his public key and you have to trust it. You could manually get it before that and in an ideal security environment you would never connect to an SSH server BEFORE you know his public key is correct. That what CAs are for, they sign a servers public key. In most SSH environments you just accept the pubkey of the server as client. This is the initial "do you want to trust this server and add it to your list?"-question. The server pubkey is stored under .ssh/known_hosts at the client in Linux systems.
The actual encryption of the connection isn't asymetical. This is a huge misconception many people have about private/public-key encryption. It would be WAY too slow. What really happens is that server and client generate a shared secret (aka a long password) which is symmetrical encryption for this one session. The client and server use asymmetrical encryption until they agree upon a shared secret. After that they switch to symmetrical encryption with this shared secret as key.
This type of encryption is the most common and called hybrid encryption, though nearly everybody (wrongly) calls it asymmetrical encryption.
An example for "real", pure asymmetrical encryption is Mail encryption with PGP, because EVERY message is encrypted asymmetrically.
Also: The shared secret isn't stored permanently, every new session a new shared secret is negociated.
Client Authentification
Это совсем другое, это то, что может быть аутентификацией на основе пароля и/или ключа. Открытый ключ клиента (расположенный в ~/.ssh/id_rsa.pub) должен присутствовать в файле authorized_keys сервера (например, для root: /root/.ssh/authorized_keys). Раньше ssh-copy-idлюди делали что-то вроде
cat ~/.ssh/id_rsa.pub | ssh root@server "cat >> ~/.ssh/authorized_keys"
для добавления вашего ключа к серверам authorized_keys.
Сертификат клиента НЕ используется для шифрования, а только для аутентификации.
ВАЖНО Править:Сделал пост более понятным, ssh-copy-idчтобы избежать недоразумений.
На данный момент ssh-copy-idэто лучший способ добавить клиентский открытый ключ на сервер. Я только что опубликовал метод, catчтобы показать, какие файлы обрабатываются с обеих сторон, чтобы показать связь между закрытыми и открытыми ключами и как они хранятся.
При использовании cat есть риск забыть, например, ">", что может привести кперезаписатьваш файл authorized_keys (в Linux ">>" означает добавление, ">" означает перезапись). Будьте ответственны при непосредственной работе с файлами конфигурации. Спасибо @Rallph за указание на это.
решение2
У сервера есть своя пара ключей. Когда вы подключаетесь к серверу SSH в первый раз, ваш клиент SSH/SFTP должен запросить у вас подтверждение, доверяете ли вы ключу хоста сервера (=открытому ключу).
Только после того, как вы тщательно проверите, что это действительно законный открытый ключ сервера, ваше соединение будет защищено. СмотретьмойстатьяГде получить отпечаток ключа хоста SSH для авторизации сервера?
Также обратите внимание, что ни ваша пара ключей, ни пара ключей сервера на самом деле не используются для шифрования данных. Это намного сложнее.
Смотрите также: