install openssh 7.6 on red hat 7.5 [duplicate]

up vote
-2
down vote

favorite

This question already has an answer here:

Upgrade OpenSSH 7.4 to later on RHEL

1 answer

I have a redhat server 7.5. I have a openssh installed on this server. The openssh is 7.4. I need to upgrade openssh 7.4 to 7.6 AS Nessus, vulnerability scanner scanned this vulnerability (Openssh <7.6) and thus need to upgrade to 7.6 or later.The details is found here, https://www.tenable.com/plugins/nessus/103781.

I found the link, https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/openssh-7.6.tar.gz but they said that this cannot be installed on Red Hat as you cant install bsd on Linux. I referred to this link, https://superuser.com/questions/577389/make-command-for-installing-openssh-on-ubuntu/

Thus I went to this link, http://www.openssh.com/portable.html to have a portable version. I used this link, https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.6p1.tar.gz.

I downloaded this file in /tmp directory.

I performed the following command,

# tar xvfz …/openssh-7.6p1.tar.gz

# cd ssh

# make obj    ←--------------------  error message

# make cleandir

# make depend

# make

# make install

I got this error when I performed the command make obj. The error is

make: *** No rule to make target 'obj'. Stop.

edited Dec 6 at 5:47

asked Dec 6 at 5:20

Abdullah Naina

143

marked as duplicate by Stephen Kitt, G-Man, RalfFriedl, Rui F Ribeiro, msp9011 Dec 6 at 7:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Can you add some details on this security reason? Red Hat usually issues advisories for such problems.
– Haxiel
Dec 6 at 5:42

I scanned the server using nessus which is a vulnerability scanner and they said openssh is less than 7.6. The details is found here tenable.com/plugins/nessus/103781
– Abdullah Naina
Dec 6 at 5:45

Red Hat prefers to backport security fixes from upstream versions over version upgrades. Even when the exact versions don't match, the RHEL packages should be as secure as the upstream version. More details here: access.redhat.com/security/updates/backporting
– Haxiel
Dec 6 at 5:50

1

I think a better approach to vulnerabilities detected by Nessus is to consider that they need to be investigated, but the fix suggested by Nessus isn’t always correct. A better question here might have been “How should I fix this vulnerability flagged by Nessus, on RHEL 7.5?”, without pre-supposing a solution (upgrading to the latest upstream version of OpenSSH, which isn’t appropriate on RHEL or indeed most distributions with long release cycles).
– Stephen Kitt
Dec 6 at 9:04

1

@Abdullah no worries, vulnerabilities are often hard to evaluate and it takes a fair amount of experience to decide what to do, especially when faced with conflicting instructions (and no doubt some pressure from your management).
– Stephen Kitt
Dec 6 at 10:23

|
show 7 more comments

up vote
-2
down vote

favorite

This question already has an answer here:

Upgrade OpenSSH 7.4 to later on RHEL

1 answer

I downloaded this file in /tmp directory.

I performed the following command,

# tar xvfz …/openssh-7.6p1.tar.gz

# cd ssh

# make obj    ←--------------------  error message

# make cleandir

# make depend

# make

# make install

I got this error when I performed the command make obj. The error is

make: *** No rule to make target 'obj'. Stop.

edited Dec 6 at 5:47

asked Dec 6 at 5:20

Abdullah Naina

143

marked as duplicate by Stephen Kitt, G-Man, RalfFriedl, Rui F Ribeiro, msp9011 Dec 6 at 7:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Can you add some details on this security reason? Red Hat usually issues advisories for such problems.
– Haxiel
Dec 6 at 5:42

I scanned the server using nessus which is a vulnerability scanner and they said openssh is less than 7.6. The details is found here tenable.com/plugins/nessus/103781
– Abdullah Naina
Dec 6 at 5:45

Red Hat prefers to backport security fixes from upstream versions over version upgrades. Even when the exact versions don't match, the RHEL packages should be as secure as the upstream version. More details here: access.redhat.com/security/updates/backporting
– Haxiel
Dec 6 at 5:50

1

I think a better approach to vulnerabilities detected by Nessus is to consider that they need to be investigated, but the fix suggested by Nessus isn’t always correct. A better question here might have been “How should I fix this vulnerability flagged by Nessus, on RHEL 7.5?”, without pre-supposing a solution (upgrading to the latest upstream version of OpenSSH, which isn’t appropriate on RHEL or indeed most distributions with long release cycles).
– Stephen Kitt
Dec 6 at 9:04

1

@Abdullah no worries, vulnerabilities are often hard to evaluate and it takes a fair amount of experience to decide what to do, especially when faced with conflicting instructions (and no doubt some pressure from your management).
– Stephen Kitt
Dec 6 at 10:23

|
show 7 more comments

up vote
-2
down vote

favorite

This question already has an answer here:

Upgrade OpenSSH 7.4 to later on RHEL

1 answer

I downloaded this file in /tmp directory.

I performed the following command,

# tar xvfz …/openssh-7.6p1.tar.gz

# cd ssh

# make obj    ←--------------------  error message

# make cleandir

# make depend

# make

# make install

I got this error when I performed the command make obj. The error is

make: *** No rule to make target 'obj'. Stop.

edited Dec 6 at 5:47

asked Dec 6 at 5:20

Abdullah Naina

143

This question already has an answer here:

Upgrade OpenSSH 7.4 to later on RHEL

1 answer

I downloaded this file in /tmp directory.

I performed the following command,

# tar xvfz …/openssh-7.6p1.tar.gz

# cd ssh

# make obj    ←--------------------  error message

# make cleandir

# make depend

# make

# make install

I got this error when I performed the command make obj. The error is

make: *** No rule to make target 'obj'. Stop.

This question already has an answer here:

Upgrade OpenSSH 7.4 to later on RHEL

1 answer

ssh rhel openssh

edited Dec 6 at 5:47

asked Dec 6 at 5:20

Abdullah Naina

143

edited Dec 6 at 5:47

asked Dec 6 at 5:20

Abdullah Naina

143

edited Dec 6 at 5:47

asked Dec 6 at 5:20

Abdullah Naina

143

asked Dec 6 at 5:20

Abdullah Naina

143

asked Dec 6 at 5:20

Abdullah Naina

143

marked as duplicate by Stephen Kitt, G-Man, RalfFriedl, Rui F Ribeiro, msp9011 Dec 6 at 7:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

marked as duplicate by Stephen Kitt, G-Man, RalfFriedl, Rui F Ribeiro, msp9011 Dec 6 at 7:32

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Can you add some details on this security reason? Red Hat usually issues advisories for such problems.
– Haxiel
Dec 6 at 5:42

I scanned the server using nessus which is a vulnerability scanner and they said openssh is less than 7.6. The details is found here tenable.com/plugins/nessus/103781
– Abdullah Naina
Dec 6 at 5:45

Red Hat prefers to backport security fixes from upstream versions over version upgrades. Even when the exact versions don't match, the RHEL packages should be as secure as the upstream version. More details here: access.redhat.com/security/updates/backporting
– Haxiel
Dec 6 at 5:50

1

I think a better approach to vulnerabilities detected by Nessus is to consider that they need to be investigated, but the fix suggested by Nessus isn’t always correct. A better question here might have been “How should I fix this vulnerability flagged by Nessus, on RHEL 7.5?”, without pre-supposing a solution (upgrading to the latest upstream version of OpenSSH, which isn’t appropriate on RHEL or indeed most distributions with long release cycles).
– Stephen Kitt
Dec 6 at 9:04

1

@Abdullah no worries, vulnerabilities are often hard to evaluate and it takes a fair amount of experience to decide what to do, especially when faced with conflicting instructions (and no doubt some pressure from your management).
– Stephen Kitt
Dec 6 at 10:23

|
show 7 more comments

Can you add some details on this security reason? Red Hat usually issues advisories for such problems.
– Haxiel
Dec 6 at 5:42

I scanned the server using nessus which is a vulnerability scanner and they said openssh is less than 7.6. The details is found here tenable.com/plugins/nessus/103781
– Abdullah Naina
Dec 6 at 5:45

Red Hat prefers to backport security fixes from upstream versions over version upgrades. Even when the exact versions don't match, the RHEL packages should be as secure as the upstream version. More details here: access.redhat.com/security/updates/backporting
– Haxiel
Dec 6 at 5:50

1

I think a better approach to vulnerabilities detected by Nessus is to consider that they need to be investigated, but the fix suggested by Nessus isn’t always correct. A better question here might have been “How should I fix this vulnerability flagged by Nessus, on RHEL 7.5?”, without pre-supposing a solution (upgrading to the latest upstream version of OpenSSH, which isn’t appropriate on RHEL or indeed most distributions with long release cycles).
– Stephen Kitt
Dec 6 at 9:04

1

@Abdullah no worries, vulnerabilities are often hard to evaluate and it takes a fair amount of experience to decide what to do, especially when faced with conflicting instructions (and no doubt some pressure from your management).
– Stephen Kitt
Dec 6 at 10:23

Can you add some details on this security reason? Red Hat usually issues advisories for such problems.
– Haxiel
Dec 6 at 5:42

I scanned the server using nessus which is a vulnerability scanner and they said openssh is less than 7.6. The details is found here tenable.com/plugins/nessus/103781
– Abdullah Naina
Dec 6 at 5:45

Red Hat prefers to backport security fixes from upstream versions over version upgrades. Even when the exact versions don't match, the RHEL packages should be as secure as the upstream version. More details here: access.redhat.com/security/updates/backporting
– Haxiel
Dec 6 at 5:50

I think a better approach to vulnerabilities detected by Nessus is to consider that they need to be investigated, but the fix suggested by Nessus isn’t always correct. A better question here might have been “How should I fix this vulnerability flagged by Nessus, on RHEL 7.5?”, without pre-supposing a solution (upgrading to the latest upstream version of OpenSSH, which isn’t appropriate on RHEL or indeed most distributions with long release cycles).
– Stephen Kitt
Dec 6 at 9:04

@Abdullah no worries, vulnerabilities are often hard to evaluate and it takes a fair amount of experience to decide what to do, especially when faced with conflicting instructions (and no doubt some pressure from your management).
– Stephen Kitt
Dec 6 at 10:23

|
show 7 more comments

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

The issue linked to in the comments refers to CVE-2017-15906 (listed on the same page).

Red Hat has documented this CVE along with its details, which is available here: https://access.redhat.com/security/cve/cve-2017-15906

According to the CVE page, an errata has been issued on this issue for RHEL 7 (RHSA-2018:0980). OpenSSH packages on RHEL 5 & 6 are not affected by this vulnerability.
The errata is available here: https://access.redhat.com/errata/RHSA-2018:0980

As per the errata page, this security issue is fixed in the following version of OpenSSH and its related packages: 7.4p1-16.el7.x86_64. If you have this version of OpenSSH on RHEL 7, you should be safe from the vulnerability. More details on the change, including upgrade instructions, are available on the errata page linked above.

The latest version of OpenSSH as per the project's homepage is 7.9. Although the RHEL package is of a lower version, it still contains all of the security patches from the upstream version. This is done by backporting - isolating the security fixes from the upstream source, and then applying them to the older package that Red Hat distributes. This allows RHEL customers to continue using a specific version of a package, while being protected against new security vulnerabilities. More of this process is explained on this page: Backporting Security Fixes.

One of the problems with backporting is the version checks employed by security scanning tools (such as the Nessus Scanner, in this case). From the above link:

Also, some security scanning and auditing tools make decisions about
vulnerabilities based solely on the version number of components they
find. This results in false positives as the tools do not take into
account backported security fixes.

This is precisely the case here, since the CVE-2017-15906 issue page for Nessus documents this explicitly:

Note that Nessus has not tested for these issues but has instead
relied only on the application's self-reported version number.

edited Dec 6 at 6:40

answered Dec 6 at 6:04

Haxiel

921310

add a comment |

1 Answer
1

active

oldest

votes

1 Answer
1

active

oldest

votes

up vote
2
down vote

accepted

The issue linked to in the comments refers to CVE-2017-15906 (listed on the same page).

Red Hat has documented this CVE along with its details, which is available here: https://access.redhat.com/security/cve/cve-2017-15906

One of the problems with backporting is the version checks employed by security scanning tools (such as the Nessus Scanner, in this case). From the above link:

Also, some security scanning and auditing tools make decisions about
vulnerabilities based solely on the version number of components they
find. This results in false positives as the tools do not take into
account backported security fixes.

This is precisely the case here, since the CVE-2017-15906 issue page for Nessus documents this explicitly:

Note that Nessus has not tested for these issues but has instead
relied only on the application's self-reported version number.

edited Dec 6 at 6:40

answered Dec 6 at 6:04

Haxiel

921310

add a comment |

up vote
2
down vote

accepted

The issue linked to in the comments refers to CVE-2017-15906 (listed on the same page).

Red Hat has documented this CVE along with its details, which is available here: https://access.redhat.com/security/cve/cve-2017-15906

One of the problems with backporting is the version checks employed by security scanning tools (such as the Nessus Scanner, in this case). From the above link:

Also, some security scanning and auditing tools make decisions about
vulnerabilities based solely on the version number of components they
find. This results in false positives as the tools do not take into
account backported security fixes.

This is precisely the case here, since the CVE-2017-15906 issue page for Nessus documents this explicitly:

Note that Nessus has not tested for these issues but has instead
relied only on the application's self-reported version number.

edited Dec 6 at 6:40

answered Dec 6 at 6:04

Haxiel

921310

add a comment |

up vote
2
down vote

accepted

The issue linked to in the comments refers to CVE-2017-15906 (listed on the same page).

Red Hat has documented this CVE along with its details, which is available here: https://access.redhat.com/security/cve/cve-2017-15906

One of the problems with backporting is the version checks employed by security scanning tools (such as the Nessus Scanner, in this case). From the above link:

Also, some security scanning and auditing tools make decisions about
vulnerabilities based solely on the version number of components they
find. This results in false positives as the tools do not take into
account backported security fixes.

This is precisely the case here, since the CVE-2017-15906 issue page for Nessus documents this explicitly:

Note that Nessus has not tested for these issues but has instead
relied only on the application's self-reported version number.

edited Dec 6 at 6:40

answered Dec 6 at 6:04

Haxiel

921310

The issue linked to in the comments refers to CVE-2017-15906 (listed on the same page).

Red Hat has documented this CVE along with its details, which is available here: https://access.redhat.com/security/cve/cve-2017-15906

One of the problems with backporting is the version checks employed by security scanning tools (such as the Nessus Scanner, in this case). From the above link:

Also, some security scanning and auditing tools make decisions about
vulnerabilities based solely on the version number of components they
find. This results in false positives as the tools do not take into
account backported security fixes.

This is precisely the case here, since the CVE-2017-15906 issue page for Nessus documents this explicitly:

Note that Nessus has not tested for these issues but has instead
relied only on the application's self-reported version number.

edited Dec 6 at 6:40

answered Dec 6 at 6:04

Haxiel

921310

edited Dec 6 at 6:40

answered Dec 6 at 6:04

Haxiel

921310

answered Dec 6 at 6:04

Haxiel

921310

answered Dec 6 at 6:04

Haxiel

921310

add a comment |

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Cfrtjryk