How do I fix a cipher mismatch issue with sftp?

Question

I'm running into an issue where a server was upgraded to RHEL 6.5, and we have automated bash scripts on an RHEL 5.9 install that connects through sftp and ssh commands.

Now, the new server only supports the ciphers aes128-ctr, aes192-ctr, and aes256-ctr.

I was able to update the ssh commands to use the -c option with aes256-ctr and this worked:

ssh -c aes256-ctr ${remote_host} ${my_command}

However, when I tried do the equivalent for sftp:

sftp -oCipher=aes256-ctr ${remote_host} <<< $'get /home/me/* me/'

I am getting an error that the client does not support the same ciphers as the server:

no matching cipher found: client arcfour256,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc server aes128-ctr,aes192-ctr,aes256-ctr

These ssh and sftp command are executed on the same RHEL 5.9 box, so I'm wondering why this works for ssh and not sftp?

Also, how do fix this so I can connect using sftp without any client side changes?

Solution

The Cipher directive is for SSH version 1 (which is not in use nowadays).

For SSH version 2, use the Ciphers:

sftp -oCiphers=aes256-ctr

See the ssh_config man page.

---

Though note that the sftp supports the -c switch too. So there's no need for using the -o.

See the sftp man page:

-c cipher

Selects the cipher to use for encrypting the data transfers.
This option is directly passed to ssh(1).

The option is supported since OpenSSH 5.4. The change is disguised as "Support most of scp(1)'s commandline arguments in sftp(1)".

---

Note the command-line argument -c is primarily an equivalent to the Ciphers directive (while it can fall back to the Cipher). Quote from the ssh man page:

-c cipher_spec

Selects the cipher specification for encrypting the session.
Protocol version 1 allows specification of a single cipher. The supported values are “3des”, “blowfish”, and “des”. For protocol version 2, cipher_spec is a comma-separated list of ciphers listed in order of preference. See the Ciphers keyword in ssh_config(5) for more information.

Comments

[StackzOfZtuff]

Crosspost: security.stackexchange.com/questions/89747/…