Как защитить SFTP-соединение обоими способами
Я хочу установить SFTP-соединение между моим компьютером и сервером.
Я сгенерировал пару ключей на своем компьютере и записал свой открытый ключ в файл «authorized_keys» на сервер. Я уверен, что это работает, потому что, когда я пытаюсь подключиться с компьютера, на котором нет моего закрытого ключа (я знаю, что никто другой не должен его иметь), мне задают пароль.
Согласно это изображение , мой сервер - Боб, а мой компьютер - Алиса. Когда сервер отправляет сообщение, он использует мой открытый ключ для его шифрования, а я использую свой закрытый ключ для его расшифровки. Но если я отправлю сообщение на сервер, оно не зашифровано, не так ли? Если да, то как он зашифрован?
Из того, что я понял об асимметричной криптографии, если я хочу зашифровать сообщения, которые я отправляю, я должен сгенерировать пару ключей на сервере и поместить его открытый ключ в свой компьютер " authorized_keys ", верно?
Как я могу проверить , что соединение защищено в обоих направлениях (отправка и получение)?
Спасибо!
В SSH-соединениях происходят две основные вещи:
Аутентификация и шифрование сервера
Сервер отправляет вам свой открытый ключ, и вы должны ему доверять. Вы можете вручную получить его до этого, и в идеальной среде безопасности вы никогда не подключитесь к SSH-серверу ДО того, как узнаете, что его открытый ключ правильный. Для этого нужны центры сертификации, они подписывают открытый ключ сервера. В большинстве сред SSH вы просто принимаете pubkey сервера в качестве клиента. Это начальный вопрос «хотите ли вы доверять этому серверу и добавить его в свой список?» - вопрос. Открытый ключ сервера хранится в .ssh / known_hosts на клиенте в системах Linux .
Фактическое шифрование соединения не является асимметричным. Это огромное заблуждение, которое многие люди имеют о шифровании с частным / открытым ключом. Это было бы ПУТЬ слишком медленно. Что действительно происходит, так это то, что сервер и клиент генерируют общий секрет (он же длинный пароль), который представляет собой симметричное шифрование для этого единственного сеанса. Клиент и сервер используют асимметричное шифрование, пока они не согласятся на общий секрет. После этого они переключаются на симметричное шифрование с этим общим секретом в качестве ключа.
Этот тип шифрования является наиболее распространенным и называется гибридным шифрованием , хотя почти все (ошибочно) называют его асимметричным шифрованием.
Примером «настоящего» чистого асимметричного шифрования является шифрование почты с помощью PGP, потому что КАЖДОЕ сообщение шифруется асимметрично.
Также: общий секрет не сохраняется постоянно, каждый новый сеанс новый общий секрет игнорируется.
Аутентификация клиента
Это совсем другое дело, это может быть аутентификация на основе пароля и / или ключа. Открытый ключ клиента (расположенный в ~ / .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 за указание на это.
У сервера есть собственная пара ключей. Когда вы впервые подключаетесь к SSH-серверу, ваш SSH / SFTP-клиент должен запросить, если вы доверяете ключу хоста сервера (= общедоступному ключу).
Только после того, как вы тщательно убедитесь, что это действительно законный общедоступный ключ сервера, ваше соединение безопасно. См. мою статью Где я могу получить отпечаток ключа хоста SSH для авторизации сервера?
Также обратите внимание, что ни ваша пара ключей, ни пара ключей сервера на самом деле не используются для шифрования данных. Это намного сложнее.
См. Также: