From Fedora Project Wiki
(remove the restart, which should happen automatically in final release)
(update links, update current status)
 
(7 intermediate revisions by 2 users not shown)
Line 54: Line 54:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1479271 #1479271]


== Detailed Description ==
== Detailed Description ==
Line 75: Line 75:


== Scope ==
== Scope ==
* Proposal owners: Create a replace script, that will replace predefined comment in the configuration with configuration generated according to current crypto policies. Make systemd trigger this script on restart.
* Proposal owners: <strike>Create a replace script, that will replace predefined comment in the configuration with configuration generated according to current crypto policies. Make systemd trigger this script on restart.</strike>
** <strike>OpenSSH package needs to be updated to preprocess configuration file and read it from runtime directory: openssh-7.5p1-4 build</strike> (too confusing for users)
** <strike>SELinux policy needs to be adjusted so sshd server can read configuration file from runtime directory: https://bugzilla.redhat.com/show_bug.cgi?id=1477613</strike> (not needed with latest approach)
** (done) Generate crypto policy as a command line arguments for SSHD: https://gitlab.com/redhat-sectech/fedora-crypto-policies/merge_requests/7
** (done) OpenSSH package picks up the crypto policy generated for command line: openssh-7.5p1-5 build
** (done) Reload sshd service after the crypto policy is changed: https://gitlab.com/redhat-sectech/fedora-crypto-policies/merge_requests/5
 
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Line 81: Line 87:
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
* Release engineering: [https://pagure.io/releng/issues/6915 #6915] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE AS WELL AS FOR SELF CONTAINED CHANGES -->
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
<!-- Does this feature require coordination with release engineering (e.g. changes to installer image generation or update package delivery)?  Is a mass rebuild required?  include a link to the releng issue.  
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication -->
Line 94: Line 100:


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
The update of manually modified <code>sshd_config</code> will not get overwritten and the crypto policies will not get picked up. The default configuration will get the crypto policies automatically.
The crypto policy is applied on the command line of <code>sshd</code> daemon and therefore any changes to the <code>sshd_config</code> will not be effective once crypto policies will get applied picked up. The default configuration will get the crypto policies automatically.
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
N/A (not a System Wide Change)


== How To Test ==
== How To Test ==
Line 165: Line 170:


== Documentation ==
== Documentation ==
Upstream documentation is available in the upstream repository for [https://github.com/nmav/fedora-crypto-policies/blob/master/update-crypto-policies.8.txt update-crypto-policies(8)].
Upstream documentation is available in the upstream repository for [https://github.com/redhat-sectechfedora-crypto-policies/blob/master/update-crypto-policies.8.txt update-crypto-policies(8)].


For OpenSSH server, there should be no difference than in other libraries except the sshd daemon is not picking up the changes on demand, but requires a restart of the services after the change.
For OpenSSH server, there should be no difference than in other libraries except the sshd daemon is not picking up the changes on demand, but requires a restart of the services after the change.
Line 180: Line 185:
-->
-->


[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF27]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 19:25, 2 November 2017


OpenSSH Server Crypto Policy

Summary

OpenSSH clients follow the system-wide crypto policy since Fedora 26. This F27 change modifies the openssh server configuration to adhere to the system-wide policy. That will allow openssh server configuration to adapt to the multiple security levels offered system-wide.

Owner

  • Name: Jakub Jelen
  • Email: jjelen@redhat.com
  • Release notes owner:

Current status

Detailed Description

Currently, the set of cryptographic algorithms used in OpenSSH is defined by upstream and Fedora just inherits what upstream considers secure. If there are special requirements for the security, manual modifications of the configuration files is required, which also prevents package manager to update the configuration file with future updates and can possibly leave enabled insecure algorithms.

Since Fedora 26 OpenSSH clients are following crypto policies defined system-wide using Include configuration option in the main ssh_config. We can not use the same method in the server, because OpenBSD did not accept yet the patch supporting the same in the server configuration (upstream bug) so we will work out other way of doing that without disrupting existing workflows.

For more information about Crypto Policy, see the appropriate wiki page Changes/CryptoPolicy describing the concept in whole.


Benefit to Fedora

All OpenSSH tools will follow system-wide crypto policy generated by update-crypto-policies(8) to ensure uniform security levels in the whole system.

The server side configuration is usually better place to defend against security vulnerabilities, rather than the user side, which does not have to have good overview of security. This will make sure they are using secure algorithms and their communiques are still secret.



Scope


  • Other developers: N/A (not a System Wide Change)
  • Release engineering: #6915 (a check of an impact with Release Engineering is needed)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

The crypto policy is applied on the command line of sshd daemon and therefore any changes to the sshd_config will not be effective once crypto policies will get applied picked up. The default configuration will get the crypto policies automatically.


How To Test

Prerequisites:

  • Make sure you have installed openssh-clients, openssh-server and crypto-policies packages
  • Make sure you have sshd server running on your system. If not, enable and start the sshd service: systemctl enable sshd && systemctl start sshd
  • Make sure you have crypto-policies configured with default profile
  • Make sure you can connect to your local sshd server with your client, such as ssh localhost

Check LEGACY profile:

  • Check that you CAN NOT connect with legacy algorithms, such as arcfour128: Run ssh -o Ciphers=arcfour128 localhost (should fail)
  • Update crypto policies to LEGACY profile. Run update-crypto-policies --set LEGACY (this will make sshd reload the configuration)
  • Check that you CAN connect with legacy algorithms, such as arcfour128: Run ssh -o Ciphers=arcfour128 localhost (should work)

Check FUTURE profile:

  • Check that you CAN connect with current algorithms that is not in FUTURE profile, such as diffie-hellman-group-exchange-sha1: Run ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1 localhost (should work)
  • Update crypto policies to FUTURE profile. Run update-crypto-policies --set FUTURE (this will make sshd reload the configuration)
  • Check that you CAN NOT connect with current algorithms that is not in FUTURE profile, such as diffie-hellman-group-exchange-sha1: Run ssh -o KexAlgorithms=diffie-hellman-group-exchange-sha1 localhost (should fail)

Post:

  • Change your crypto policies back to DEFAULT. Run update-crypto-policies --set FUTURE (this will make sshd reload the configuration)

Note: specifying the algorithms on command line or in per-user client configuration overwrites system-wide policy. The same can be done with the server configuration, by specifying the options before the expanded crypto-policies comment.


User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

Upstream documentation is available in the upstream repository for update-crypto-policies(8).

For OpenSSH server, there should be no difference than in other libraries except the sshd daemon is not picking up the changes on demand, but requires a restart of the services after the change.


Release Notes