Назад | Перейти на главную страницу

Как защитить SFTP-соединение обоими способами

Я хочу настроить SFTP-соединение между моим компьютером и сервером.

Я создал пару ключей на своем компьютере и записал свой открытый ключ в файл «authorized_keys» на сервере. Я уверен, что это работает, потому что, когда я пытаюсь подключиться с компьютера, на котором нет моего закрытого ключа (я знаю, что никто другой не должен его иметь), запрашивается пароль.

В соответствии с это изображение, мой сервер - Боб, а мой компьютер - Алиса. Когда сервер отправляет сообщение, он использует мой открытый ключ для его шифрования, а я использую свой закрытый ключ для его расшифровки. Но если я отправлю сообщение на сервер, оно не зашифровано, не так ли? Если да, то как это зашифровано?

Из того, что я понял об асимметричной криптографии, если я хочу зашифровать отправляемые сообщения, я должен сгенерировать пару ключей на сервере и поместить его открытый ключ в файл «authorized_keys» на моем компьютере, верно?

Как я могу проверить что соединение защищено в обоих направлениях (отправка и получение)?

Спасибо!

В соединениях SSH происходят две основные вещи:

Аутентификация и шифрование сервера

Сервер отправляет вам свой открытый ключ, и вы должны ему доверять. Вы можете вручную получить его до этого, и в идеальной среде безопасности вы никогда не подключитесь к серверу SSH ДО того, как узнаете, что его открытый ключ правильный. Для этого нужны центры сертификации, они подписывают открытый ключ сервера. В большинстве сред SSH вы просто принимаете pubkey сервера в качестве клиента. Это начальный вопрос «хотите ли вы доверять этому серверу и добавить его в свой список?» - вопрос. Ключ 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 , чтобы показать, какие файлы обрабатываются с обеих сторон, чтобы показать связь между частным и открытым ключом и способ их хранения.

При использовании кошки есть риск забыть, например, ">", который перезаписывать ваш файл authorized_keys (в Linux ">>" означает добавление, ">" означает перезапись). Будьте ответственны при непосредственном манипулировании файлами конфигурации. Спасибо @Rallph за указание на это.

У сервера есть своя пара ключей. Когда вы впервые подключаетесь к SSH-серверу, ваш SSH / SFTP-клиент должен получить запрос, если вы доверяете ключу хоста сервера (= открытый ключ).

Только после того, как вы тщательно проверите, что это действительно законный открытый ключ сервера, ваше соединение будет безопасным. Видеть мой статья Где я могу получить отпечаток ключа хоста SSH для авторизации сервера?

Также обратите внимание, что ни ваша пара ключей, ни пара ключей сервера на самом деле не используются для шифрования данных. Это намного сложнее.

Смотрите также: