7

I have a Debian 8 server for a customer that is failing a PCI scan, presumably running: nmap -p 22 -sV customer.edu

which returns

22/tcp open ssh OpenSSH 6.7p1 Debian 5+deb8u7

This should be easy, given my /etc/apt/sources.list is this:

deb http://mirror.rackspace.com/debian jessie main
deb-src http://mirror.rackspace.com/debian jessie main
deb http://mirror.rackspace.com/debian-security/ jessie/updates main
deb-src http://mirror.rackspace.com/debian-security/ jessie/updates main
deb http://packages.dotdeb.org jessie all
deb-src http://packages.dotdeb.org jessie all
deb http://ftp.us.debian.org/debian/ jessie main contrib non-free
deb-src http://ftp.us.debian.org/debian/ jessie main contrib non-free
deb http://ftp.debian.org/debian jessie-backports main
deb http://security.debian.org/ jessie/updates main contrib non-free

sudo apt-get upgrade openssh-server returns:

Calculating upgrade... openssh-server is already the newest version.

Is there a better way to get the latest OpenSSH server?

I attempted to download it, install its OpenSSL 1.0.2-stable dependency in /usr/local/ but having serious troubles with it failing.

Are my choices to find a better source in apt-get, or attempt to install it and its OpenSSL dependency in /usr/local and manually point systemctl to those binaries?

sam452
  • 269
  • 1
  • 6
  • 15
  • You probably should be looking at upgrading to stretch. – Zoredache Feb 19 '19 at 23:24
  • From what I researched, an in-place upgrade is not advised, but rather a new Debian stretch install and migrate our apps to it. Would you agree? – sam452 Feb 20 '19 at 10:55
  • 1
    Depends on what you are running and how well managed the system is. I have upgraded some systems in place without issue. Though I also have a well tested backup systems and can easily revert if things go wrong. – Zoredache Feb 20 '19 at 17:39

2 Answers2

6

failing a PCI scan

Document for your auditor the version of the package installed. Reference security updates regarding OpenSSH, in this case from Debian. Possibly cross reference relevant CVEs.

Parsing a version number is fragile. Stable distros generally do not upgrade the version, but apply their own patches.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Yes, this release resolves most of the PCI scan. Except one failure reports "SSH server is using a small public key". Searching suggests this was issue prior to OpenSSH 7. Since your link is listing vulnerabilities, it's unclear if patches have resolved this complaint? – sam452 Feb 20 '19 at 14:36
  • That is for you to determine comparing the rationale from the audit to change log and patches of the openssh package you are using. If you have issues with this, ask another question. – John Mahowald Feb 21 '19 at 21:38
-2

I originally published this script here install-newer-openssh .
Then the most updated version will be there!
However, to make it easier I transcribe it here...

PLUS!

A SEVERE VULNERABILITY (CVE-2023-38408) has been discovered in OpenSSH in versions prior to 9.3p2 which is the case for virtually all server Linux distros. CVE-2023-38408 is a vulnerability that allows remote code execution and is present in the SSH agent forwarding feature, especially against "PKCS#11" providers. Leveraging SSH agent support of "PKCS#11" under specific conditions allows attackers to execute remote code through a forwarded agent socket.

So it's important to update the OpenSSH Service in use on your server to a newer version!

MORE INFORMATION: https://github.com/kali-mx/CVE-2023-38408 , https://tryhackme.com/room/cve202338408 , https://nvd.nist.gov/vuln/detail/CVE-2023-38408 .


OpenSSH Service - Install a newer version (Debian)

Introduction

Using a OpenSSH service newer version (9.4 at the time of this guide) is easy and crucial for security.

We will install a OpenSSH service newer version while keeping and disabling the one installed by the package manager (Debian official repositories).

Tested on Debian GNU/Linux 11 (bullseye).

NOTE: For easier understanding, we will refer to the version installed by the package manager (Debian official repositories) as the OpenSSH service repo version.

IMPORTANT: Installing a OpenSSH service newer version alongside the OpenSSH service repo version is recommended because components of the OpenSSH service repo version are used by other components and packages, and its absence can be a source of problems.

Install the required packages

Install the necessary packages to build and run the OpenSSH service newer version...

apt -y install autoconf
apt -y install build-essential
apt -y install cmake
apt -y install libssh-dev
apt -y install libtool
apt -y install netcat
apt -y install wget

Download and build the OpenSSH service newer version

Commands to download and build...

wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.4p1.tar.gz
OPENSSH_VER="9.4p1"
tar -xvf openssh-${OPENSSH_VER}.tar.gz
cd openssh-${OPENSSH_VER}
./configure --prefix=/opt/openssh-${OPENSSH_VER}
make
make install
cd ..
rm -rf openssh-${OPENSSH_VER}.tar.gz

TIP: OpenSSH service newer versions can be found at https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/ .

IMPORTANT: You should use a portable version.

Create a symbolic link (symbolic link) so that we can update the OpenSSH service more easily in the future, reusing some configurations...

ln -s /opt/openssh-${OPENSSH_VER} /opt/openssh-latest

Change the OpenSSH service repo version configuration

Change the OpenSSH service repo version port in /etc/ssh/sshd_config configuration file by changing the "#Port 22" parameter to "Port 2222", for example.

NOTE: The configuration file for the OpenSSH service newer version will be in the path /opt/openssh-latest/etc/sshd_config.

Create the default environment file for the OpenSSH service newer version

Commands to create the default environment file and a folder for it...

mkdir -p "/opt/openssh-latest/default"
read -r -d '' FILE_CONTENT << 'HEREDOC'
BEGIN
# Default settings for OpenSSH Server.

# Options to pass to sshd.
SSHD_OPTS=

END
HEREDOC
echo -n "${FILE_CONTENT:6:-3}" > '/opt/openssh-latest/default/ssh'

Create service configuration files (systemd)

Commands to create the "ssh-latest.service" file...

read -r -d '' FILE_CONTENT << 'HEREDOC'
BEGIN
[Unit]
Description=OpenBSD Secure Shell server
Documentation=man:sshd(8) man:sshd_config(5)
After=network.target auditd.service
ConditionPathExists=!/opt/openssh-latest/etc/sshd_not_to_be_r

[Service]
EnvironmentFile=-/opt/openssh-latest/default/ssh
ExecStartPre=/opt/openssh-latest/sbin/sshd -t
ExecStart=/opt/openssh-latest/sbin/sshd -D $SSHD_OPTS
ExecReload=/opt/openssh-latest/sbin/sshd -t
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartPreventExitStatus=255
Type=exec
RuntimeDirectory=sshd-latest
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target
Alias=sshd-latest.service

END
HEREDOC
echo -n "${FILE_CONTENT:6:-3}" > "/usr/lib/systemd/system/ssh-latest.service"

Commands to create the "ssh-latest@.service" file...

read -r -d '' FILE_CONTENT << 'HEREDOC'
BEGIN
[Unit]
Description=OpenBSD Secure Shell server per-connection daemon
Documentation=man:sshd(8) man:sshd_config(5)
After=auditd.service

[Service]
EnvironmentFile=-/opt/openssh-latest/default/ssh
ExecStart=/opt/openssh-latest/sbin/sshd -i $SSHD_OPTS
StandardInput=socket
RuntimeDirectory=sshd-latest
RuntimeDirectoryMode=0755

END
HEREDOC
echo -n "${FILE_CONTENT:6:-3}" > "/usr/lib/systemd/system/ssh-latest@.service"

Commands to create the "ssh-latest.socket" file...

read -r -d '' FILE_CONTENT << 'HEREDOC'
BEGIN
[Unit]
Description=OpenBSD Secure Shell server socket
Before=ssh-latest.service
Conflicts=ssh-latest.service
ConditionPathExists=!/opt/openssh-latest/etc/sshd_not_to_be_r

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target

END
HEREDOC
echo -n "${FILE_CONTENT:6:-3}" > "/usr/lib/systemd/system/ssh-latest.socket"

Commands to create the "rescue-ssh-latest.target" file...

read -r -d '' FILE_CONTENT << 'HEREDOC'
BEGIN
[Unit]
Description=Rescue with network and ssh
Documentation=man:systemd.special(7)
Requires=network-online.target ssh-latest.service
After=network-online.target ssh-latest.service
AllowIsolate=yes

END
HEREDOC
echo -n "${FILE_CONTENT:6:-3}" > "/usr/lib/systemd/system/rescue-ssh-latest.target"

Service configurations (systemd)

Disable the OpenSSH service repo version...

systemctl disable ssh.service
systemctl disable ssh.socket

Enable the OpenSSH service newer version...

systemctl enable ssh-latest.service
systemctl enable ssh-latest.socket

Reboot your system...

reboot

Confirm the version of the OpenSSH service newer version

Confirm the version via the binary...

/opt/openssh-latest/bin/ssh -V

Confirm the version via the service...

echo | nc 127.0.0.1 22

[Ref(s).: https://gist.github.com/jtmoon79/745e6df63dd14b9f2d17a662179e953a ]

  .~.  Have fun! =D
  /V\  
 // \\ Tux
/(   )\
 ^`~'^ 
Eduardo Lucio
  • 269
  • 4
  • 14
  • 2
    This advice is **DANGEROUS** as replacing the packaged version from the official repositories with a self-built one **disables automatic updates**. – Esa Jokinen Aug 31 '23 at 04:14
  • 2
    For the CVE-2023-38408: monitor the [Debian security tracker](https://security-tracker.debian.org/tracker/CVE-2023-38408); it will be *backported* soon, as explained in the accepted answer. – Esa Jokinen Aug 31 '23 at 04:18
  • 1
    Also, while waiting for the patch, it is possible to mitigate the risks from this vulnerability: "Restrict PKCS#11 providers: Configure OpenSSH to allow only specific and trusted PKCS#11 providers. By limiting the use of PKCS#11 providers to known and verified sources, you can reduce the potential attack surface and minimize the risk of exploitation." (From [How to fix CVE-2023-38408 in OpenSSH](https://vulcan.io/blog/how-to-fix-cve-2023-38408-in-openssh/).) – Esa Jokinen Aug 31 '23 at 04:25
  • @EsaJokinen The official repositories version is kept installed, just disabled. – Eduardo Lucio Aug 31 '23 at 13:07
  • 1
    @EsaJokinen Interestingly your reference cites "**Upgrade to OpenSSH 9.3p2 or later:** Upgrading to the latest version of OpenSSH is crucial as it includes critical patches to mitigate the vulnerability. Ensure that all relevant systems and servers are promptly updated to the recommended version or a higher one. ". – Eduardo Lucio Aug 31 '23 at 14:07
  • 2
    Yes, and it also says that: "The vulnerability lies in the SSH-agent’s source code, enabling a remote attacker with access to the remote server where a user’s SSH-agent is forwarded to load and unload shared libraries in /usr/lib* **on the user’s workstation**." How does upgrading the `sshd` server exactly help fixing this **problem affecting the `ssh` client**? – Esa Jokinen Aug 31 '23 at 16:12
  • 1
    Furthermore, on Debian, the agent forwarding is disabled by the default configuration: `ssh -G localhost | grep forwardagent` says `no`. This means that for this vulnerability to be effective one must have a certain configuration. That's probably why the patch is not backported in a hurry. Neither should anyone recklessly apply suggestions that a) does not fix the actual problem as the vulnerability isn't fully understood b) turn production systems into a state where the updates from the repositories aren't patching the running version anymore. – Esa Jokinen Aug 31 '23 at 16:25
  • @EsaJokinen Another interesting question would be: When will a distribution like Debian GNU/Linux 11 (bullseye) get OpenSSH version 9.4p1 (or even higher)? The answer is likely to be "Never!" Using very old versions of certain packages, by itself, can be a security problem since corrections of other natures also occur, however people cannot keep their legacy systems and services stopped. Sorry, but I still haven't been able to find anything from a practical point of view that justifies your placements and your unproductive downvote... – Eduardo Lucio Aug 31 '23 at 17:37
  • 1
    Stable distributions are designed for production environments that are required to guarantee long-term compatibility i.e. that the feature set of the software does not change suddenly. That's why they have fixed major versions of the software and backport the security fixes to older versions; giving **long-term support**. Frankly, new versions come with new bugs and vulnerabilities that could be as bad or even worse. That's why production servers use versions that have been tested rigorously & longer. The audience here has other goals than playing with the newest stuff. Hence the downvote. – Esa Jokinen Aug 31 '23 at 17:59
  • @EsaJokinen 1# "The audience here has other goals than playing with the newest stuff." -> Speak for yourself. 2# "could be as bad or even worse" -> It is very unlikely that a mature community and a mature project like OpenSSH make mistakes of this nature, again... Speak for yourself. 3# I think what **you want is to impose your personal vision** and criticize the work of those who want to contribute. Be kind! – Eduardo Lucio Aug 31 '23 at 18:31
  • 1
    I think @EsaJokinen has a very heavy point here: doing such tinkering in production server is a very bad practice — and as Esa just explained, it does not fix the problem, the problem is on the client side, not in the server. – Vesa Linja-aho Aug 31 '23 at 18:32
  • Well, I bring an elegant and well-documented solution here that poses no risk to anyone who uses it. I can guarantee! For me, free software is a solution and not a bunch of innocuous criticism. Luckily, I'm not part of that current of thought. So I leave here my excellent contribution and your opinion to those who are interested. All the best! – Eduardo Lucio Aug 31 '23 at 18:38
  • Well, fixing the vulnerability for any of the versions still affected would be called a contribution to the open source. Using a code repository to host a markdown formatted web page that suggests breaking a working distribution while leaving it vulnerable to the very vulnerability it promises to take care of... unlikely. It sadly belittles the work of those who actually keep the LTS distributions secure. – Esa Jokinen Aug 31 '23 at 18:47
  • "leaving it vulnerable to the very vulnerability it promises to take care of" -> Source: @EsaJokinen opinion. – Eduardo Lucio Aug 31 '23 at 19:19
  • Source, e.g., [Qualys Security Advisory CVE-2023-38408](https://www.qualys.com/2023/07/19/cve-2023-38408/rce-openssh-forwarded-ssh-agent.txt), emphasis is mine: "Typically, a system administrator (Alice) runs ssh-agent **on her local workstation**, connects to a remote server with ssh, and enables ssh-agent forwarding with the `-A` or `ForwardAgent` option, thus **making her ssh-agent (which is running on her local workstation) reachable from the remote server**." – Esa Jokinen Sep 01 '23 at 05:23
  • @EsaJokinen Man... You want to impose your point of view anyway... But you can't do the obvious... Proving in a practical way that there is a security flaw in my approach, it's just rhetoric. Go rest, sort out your things... You're really stuck, free software isn't that. For God's sake!‍ – Eduardo Lucio Sep 01 '23 at 14:09