On 24 February 2018 at 07:42, Colin Watson <cjwatson@xxxxxxxxxx> wrote: > On Fri, Feb 23, 2018 at 02:45:55PM +0100, mlrx wrote: >> May I infer that when an option is deprecated it can simply be deleted >> and consider that it is a working rule of the dev team (and therefore >> adopt this mode of operation for the future)? Anything that the server (or client for that matter) reports as "line N: FooOption option Deprecated" are no-ops and may safely be removed from the config. > I'm not a member of the OpenSSH development team, only a packager and > occasional contributor, so you can't infer anything like that from my > message. It wouldn't surprise me if there've been some times when more > migration work is required. Times where migration work is required are user-visible changes of behaviour and documented in the release notes[0] for that release, usually under "Potentially-incompatible changes". The specific options in this thread (KeyRegenerationInterval[1]) 7.6p1: * ssh(1): delete SSH protocol version 1 support, associated configuration options and documentation. 7.5p1: * This release deprecates the sshd_config UsePrivilegeSeparation option, thereby making privilege separation mandatory. Privilege separation has been on by default for almost 15 years and sandboxing has been on by default for almost the last five. [0] https://www.openssh.com/releasenotes.html [1] https://man.openbsd.org/OpenBSD-6.0/sshd_config.5#KeyRegenerationInterval -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
