Создание пары SSH с помощью AES-256-CBC
<<< запускается “здесь строка”: строка расширяется и питается к stdin программы. (В Вашем случае нет большой части случая расширения.) Это эквивалентно этому:
echo ddd | md5sum
С другой стороны, << запускается здесь документ. Все следующие строки до одной содержащей маркер ddd будет включать вход программы. (Необходимо использовать маркер, который вряд ли появится в данных.) Вы могли достигнуть того же эффекта как выше подобного это:
md5sum <<END
ddd
END
Существует одно различие между <<END и <<'END': Без кавычек, любых переменных, escape-последовательности и т.д. в здесь документ будет расширен, как обычно.
Вы не создаете ключ, используемый aes при использовании ssh-keygen . Поскольку aes является симметричным шифром , его ключи не приходят попарно. На обоих концах связи используется один и тот же ключ.
Ключ, созданный ssh-keygen, использует криптографию с открытым ключом для аутентификации. Из руководства ssh-keygen :
ssh-keygen generates, manages and converts authentication keys for
ssh(1). ssh-keygen can create RSA keys for use by SSH protocol version 1
and DSA, ECDSA, Ed25519 or RSA keys for use by SSH protocol version 2.
Из руководства ssh :
Public key authentication works as follows: The scheme is based on
public-key cryptography, using cryptosystems where encryption and
decryption are done using separate keys, and it is unfeasible to derive
the decryption key from the encryption key. The idea is that each user
creates a public/private key pair for authentication purposes. The
server knows the public key, and only the user knows the private key.
ssh implements public key authentication protocol automatically, using
one of the DSA, ECDSA, Ed25519 or RSA algorithms.
Проблема криптографии с открытым ключом в том, что она довольно медленная. Симметричная криптография ключей намного быстрее и используется ssh для фактической передачи данных. Ключ, используемый для симметричной криптографии, генерируется на лету после установления соединения (цитата из руководства sshd ):
For protocol 2, forward security is provided through a Diffie-Hellman key
agreement. This key agreement results in a shared session key. The rest
of the session is encrypted using a symmetric cipher, currently 128-bit
AES, Blowfish, 3DES, CAST128, Arcfour, 192-bit AES, or 256-bit AES. The
client selects the encryption algorithm to use from those offered by the
server. Additionally, session integrity is provided through a
cryptographic message authentication code (hmac-md5, hmac-sha1, umac-64,
umac-128, hmac-ripemd160, hmac-sha2-256 or hmac-sha2-512).
Если вы хотите использовать aes256-cbc , вы должны указать его в командной строке с помощью параметра -c, в его самом основном виде это будет выглядеть следующим образом:
$ ssh -c aes256-cbc user@host
Вы также можете указать предпочтительный выбор шифров в ssh _ config , используя список, разделенный запятыми. Однако не рекомендуется тычать с дефолтами, поскольку это лучше оставить на усмотрение экспертов. Есть много соображений и многолетний опыт, которые перешли к выбору значений по умолчанию разработчиками OpenSSH.
Если вы хотите изменить шифр, используемый для генерации закрытых/открытых ключей для ssh-соединения, вы можете сделать это:
openssl genrsa -aes256 -out private.key 4096
ssh-keygen -y -f private.key > public.key.pub
см. шифры, доступные для вашего ssh-соединения с:
ssh -Q cipher
ваш демон (sshd -удаленный хост, к которому вы подключаетесь )также должен поддерживать тип шифрования, с которым вы подключаетесь. Я думаю, что шифры, используемые на вашем sshd, такие же, как и ssh, установленные на вашем удаленном хосте. Итак, выполнив ssh -Q cipherна своем удаленном хосте, вы увидите, какие шифры поддерживает ваш sshd.
PS :Если вы попытаетесь сгенерировать открытый ключ с помощью openssl, он не будет работать для ssh-подключения не только потому, что он имеет другой формат, но и кодируется по-другому. Там этот пост , который показывает, как конвертировать между ними.