-1

I work in a government agency. We are running a sftp client and sftp-server on a DMZ system where we receive and send files over the internet.

Our environment:

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

Linux version 3.10.0-1160.102.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC) ) #1 SMP Mon Sep 25 05:00:52 EDT 2023

Red_Hat_Enterprise_Linux-Release_Notes-7-en-US-7-2.el7.noarch

redhat-release-server-7.9-8.el7_9.x86_64

Intel(R) Xeon(R)

Our problem is that one of our partners want to upgrade the openssh version but we do not know what version is the most stable and secure. I have been looking at the OpenSSH site and elsewhere but have not found any good answer.

Our question: What openssh version on Linux do you recommend when it comes to stability and security ( sftp security ) ?

Regards

Anders

3 Answers 3

0

Since you are already using REL, I would suggest staying with it although you should upgrade to version 8 or 9. As @tink has pointed out, REL backports security patches into their packages without changing the major/minor version numbers so your will be very safe there.

If possible, you might want to enable FIPS 140-2 to enforce a list of NIST-approved ciphers and MACs. Failing that, you can configure sshd to use a restricted set of ciphers that are known to be more secure.

Finally, a question. If your partner wants to switch openssh versions, how does that affect the server that you're running?

7
  • Our partner upgraded to OpenSSH 8.4 on their server without telling us about it. All SFTP file transfers between us stopped working. They could no longer send files to our server. Our partner had to go back to an earlier version of OpenSSH. Now they want us to upgrade to OpenSSH 8.4, but we feel we must take it slowly and investigate what is best first. We also have other partners with whom we receive and send files and all of that must continue to work and if we upgrade OpenSSH so must they.
    – Anders
    Commented Apr 24 at 10:59
  • @Anders In this case I doubt that the version of openSSH is the real problem. Most likely the partner changed the list of acceptable ciphers/MACs when their version was upgraded. Assuming that you have some kind of contractual authority over them, you need to insist on coordinating changes in allowed cipher lists. The list is not strictly dependent on the openSSH version but in the settings in /etc/ssh/sshd_config. Within reasonable security limits, you should be able to reach a lowest common denominator acceptable to all of your partners.
    – doneal24
    Commented Apr 24 at 19:12
  • Thanks for your answer. Even though I work to some degree with ciphers and encryption I am not an expert. The other partners authenticate through public and private ssh keys. However, the partner who upgraded to OpenSSH 8.4 authenticate through password. But I guess that does not matter in this case. Is that correct?
    – Anders
    Commented Apr 25 at 14:46
  • @Anders The authentication key is not the issue here. Before the user is authenticated, the two systems will negotiate how they will encrypt the connection. The cipher list used by the server is defined in sshd_config using the keywords Ciphers and MACs. If the client will not support any of these ciphers, the connection fails. If your partner adds -vv to their command line, they will see the ciphers they're offering and the ones your server is accepting. In comparing the two lists you may be able to reach some compromise.
    – doneal24
    Commented Apr 25 at 18:18
  • @Anders And, since you are in a government agency (US federal?), you'll likely want to harden your configuration to put it in line with NIST 800-53 and require your partners to conform to these restrictions. In my sshd_config, I have Ciphers aes128-ctr,aes192-ctr,aes256-ctr and MACs hmac-sha1,[email protected]. These will work with any modern ssh clients. These settings have worked with CentOS 7 and OEL 8.
    – doneal24
    Commented Apr 25 at 18:22
0

In general: try to stay current and apply all security patches. So latest is best (normally). There are vulnerabilities from 2017 on OpenSSH prior to 7.6, so if you are concerned about security, you should have been upgrading a long time ago.

As for stability: if you use RedHat, using ssh from the RedHat repositories will give you a stable version.

You can always read the release notes end search for the security advisories. To quote:

  • ssh(1), sshd(8) in OpenSSH prior to version 9.6. Weakness in initial key exchange ("Terrapin Attack")
  • ssh-agent(1) in OpenSSH between 8.9 and 9.5 (inclusive) Incomplete application of destination constraints to smartcard keys.
  • ssh-agent(1) in OpenSSH between and 5.5 and 9.3p1 (inclusive) remote code execution relating to PKCS#11 providers
  • ssh(1) in OpenSSH between and 6.5 and 9.1 (inclusive). ssh(1) failed to check DNS names returned from libc for validity.
  • sshd in OpenSSH between 6.2 and 8.7 (inclusive). sshd(8) failed to correctly initialise supplemental groups when executing an AuthorizedKeysCommand or AuthorizedPrincipalsCommand

I would say, anything below 9.6 is a security issue.

Really: staying on a version this old is a bigger problem in terms of stability and security then doing a full upgrade to the latest version.

1
  • Thank you. I appreciate your reply.
    – Anders
    Commented Apr 23 at 17:57
0

That will depend on your service level with redhat. 7 goes out of support 2 in two months.

https://access.redhat.com/product-life-cycles?product=Red%20Hat%20Enterprise%20Linux,OpenShift%20Container%20Platform%204

Redhat typically applies/backports security patches w/o changing the major version numbers of the base packages; this is true for both kernel and applications. I currently don't have access to any redhat or centos machines, so can't verify when your OpenSSH_7.4p1 was last updated (try something like rpm -qa --last|grep ssh, I haven't used RHEL in yonks).

1
  • Thanks for your advice.
    – Anders
    Commented Apr 23 at 18:05

Not the answer you're looking for? Browse other questions tagged .