OpenSSH 4.4

what is the best way to upgrade to this version without upsetting the virtualmin compatability OR remove GSSAPI authentication?

Status: 
Closed (fixed)

Comments

Well, I don't see Virtualmin compatibility as being an issue.

However, being as CentOS support only goes up to 4.3p2, that means you'd have to install from an alternate source from the CentOS repo's.

We'd typically recommend sticking with the CentOS packages when possible -- going outside of that tends to cause hardship, and makes it more difficult to perform security updates when new versions are available :-)

Are you sure the features in version 4.4 warrant doing a custom SSH install?

However, reviewing the Changelog for version 4.4, it does appear it continues to support GSSAPI authentication, so installing that shouldn't break it unless the config file syntax changed (which seems unlikely).

Aha!

The main issue is GSSAPI authentication - here is the text from our vunerability test:

The remote SSH server is affected by multiple vulnerabilities.

Description :

According to its banner, the version of OpenSSH installed on the remote host contains a race condition that may allow an unauthenticated remote attacker to crash the service or, on portable OpenSSH, possibly execute code on the affected host. In addition, another flaw exists that may allow an attacker to determine the validity of usernames on some platforms. Note that successful exploitation of these issues requires that GSSAPI authentication be enabled.

See also: CVE: Plugin Category Priority

http://www.openssh.com/txt/release-4.4

Howdy -- aha! That helps.

Here's the thing -- many/most security scanners raise flags on the versions of apps they see, rather than specific vulnerabilities they actually detect.

RedHat, and thus CentOS, do something that drives security scanners nuts... in order to maintain stability in their distros, rather than upgrading to new versions of daemons (such as SSH) whenever fixes come out, they actually backport the fix to the version that shipped with their distro.

So while it looks as if the version of SSH they have is older and full of holes, it's not!

It's actually as safe as any other SSH version out there... and much safer and more stable than custom compiling one.

Because of all that, security scanners typically have a "false positive" option you can select (which you can use if you're trying to pass the scan for someone else, due to a PCI Compliance test for example).

For a false positive, just say that you're using the most recent version available for your distro, which contains all the fixes backported into the version you have.

You're also welcome to GSSAPI authentication, if you're concerned about it. Just set "GSSAPIAuthentication no" in /etc/ssh/sshd_config, and then restart the SSH daemon.

great, thanks.

These false positives are winding me up - I also got this:

Security hole found on port/service "microsoft-ds (445/tcp)"

Plugin   "Microsoft Hotfix for KB835732 (SMB check)"    

Category     "Windows "     

Priority     "Urgent"

Synopsis : Arbitrary code can be executed on the remote host due to a flaw in the LSASS service. Description : The remote version of Windows contains a flaw in the function 'DsRolerUpgradeDownlevelServer' of the Local Security Authority Server Service (LSASS) that may allow an attacker to execute arbitrary code on the remote host with SYSTEM privileges. A series of worms (Sasser) are known to exploit this vulnerability in the wild.

   Solution :

Microsoft has released a set of patches for Windows NT, 2000, XP and 2003 :

http://www.microsoft.com/technet/security/bulletin/ms04-011.mspx

which you have to laugh at (or else you will cry!!

Heh, indeed ;-)

Okay, I'll mark this as "Fixed", as you should be able to do what you need by marking all the above as false positives.

If you need further help, just let us know!

Automatically closed -- issue fixed for 2 weeks with no activity.