#1538 PR `merged`: Only support OpenSSH 3.1 and later for SSH setup¶

Labels: enhancement, bug, documentation, cleanup, fixed / solved / done

jsmeix opened issue at 2017-10-19 10:55:¶

This intends to implement what is described in
https://github.com/rear/rear/pull/1530#issuecomment-337526810
and subsequent comments.

This removes "out-of-the-box" support in ReaR for
other secure shell software like CentrifySSH
cf. https://github.com/rear/rear/issues/836
but it does not make OpenSSH mandatory for ReaR
so that the initial problem in
https://github.com/rear/rear/issues/836
should not re-appear.

In default.conf it is now described how to set up ReaR
with a secure shell software other than OpenSSH >= 3.1
basically via

SSH_FILES='no'
COPY_AS_IS=( "${COPY_AS_IS[@]}" my secure shell software files )
REQUIRED_PROGS=( "${REQUIRED_PROGS[@]}" my secure shell programs )

Currently I have not yet tested it.

jsmeix commented at 2017-10-19 11:14:¶

FWIW:

At least I cannot maintain code in ReaR that supports
non OpenSSH >= 3.1 like "third-party" secure shell software
so that I would appreciate it to clean up and simplify
SSH support in ReaR to only support OpenSSH >= 3.1.

jsmeix commented at 2017-10-19 11:49:¶

The original issue in https://github.com/rear/rear/issues/836
is back because in rescue/default/500_ssh.sh

grep -h 'sftp' /etc/sshd_co[n]fig /etc/ssh/sshd_co[n]fig /etc/openssh/sshd_co[n]fig

hangs up if none of the files exists because plain

grep -h 'sftp'

endlessly waits for input on stdin.

jsmeix commented at 2017-10-19 12:49:¶

@OliverO2
now I have in rescue/default/500_ssh.sh

local files_for_grep=( /etc/sshd_co[n]fig /etc/ssh/sshd_co[n]fig /etc/openssh/sshd_co[n]fig )
...
... grep -h 'sftp' ${files_for_grep[*]} 2>/dev/null

I wonder if /etc/sshd_config or /etc/openssh/sshd_config
can actually happen when ReaR only supports
OpenSSH >= 3.1 with its default directories.

On my SLES10, SLES11, and SLES12 systems
I have only /etc/ssh/sshd_config.

According to the

git log -p --follow usr/share/rear/rescue/default/500_ssh.sh

output

grep sftp /etc/sshd_co[n]fig /etc/ssh/sshd_co[n]fig

is there since the beginning and was enhanced to

grep sftp /etc/sshd_co[n]fig /etc/ssh/sshd_co[n]fig /etc/openssh/sshd_co[n]fig

via
https://github.com/rear/rear/commit/d5f32d391aa0909c40d55a9c37a545f5c99d5b37
unfortunately - as often - with a comment that only
tells about the WHAT but not about the WHY.

I could also see directly in the code WHAT was changed
so that a comment that tells about WHAT is useful
but not strictly required.

In contrast leaving out the WHY could be a reason
to assume there is no longer a reason behind so that
we might clean up (i.e. remove) such inexplicable stuff?

At least for me it seems it may have become obsolete
nowadays bacause I have only /etc/ssh/sshd_config.

Cf.
https://github.com/rear/rear/pull/1530#issuecomment-337493807

OliverO2 commented at 2017-10-19 13:15:¶

Not really: Having /etc/sshd_config or /etc/openssh/sshd_config with OpenSSH >= 3.1 would be a deviation from the original distribution layout. In theory, of course this could be done, but why would a package maintainer want to do this?

I'd treat the above directories as obsolete and safe to remove after all these years.

I think it also makes sense to remove the previously existing sketchy support for Centrify SSH files, as (if I am correct) Centrify SSH binaries are not copied to rescue media. Otherwise ReaR would run the risk of exposing an additional set of Centrify-specific secrets by accident, though Centrify SSH would be unusable on a rescue system anyway.

jsmeix commented at 2017-10-19 13:46:¶

Hooray!
I will remove them from the code.

jsmeix commented at 2017-10-19 14:14:¶

There is no longer any 'centrify' (ignore case) in the code
or in a documentation file.

Since
https://github.com/rear/rear/pull/1538/commits/67130817ef40ae26f86aef4a6543a2ba34a4e590
there is no longer 'openssh' in the code except in comments
and in doc/user-guide/02-getting-started.adoc as

The most basic requirement for Relax-and-Recover is having bash,
and ubiquitous Linux tools like:
...
 - ssh (openssh-clients)

jsmeix commented at 2017-10-19 14:16:¶

Things work still well for me so that I will "just merge" this one
so that also others test it in the GitHub master code because
in case of issues I need issue reports soon to be able to fix
things before the ReaR 2.3 release.

jsmeix commented at 2017-10-19 14:32:¶

With this pull request merged there is now
only support for OpenSSH 3.1 and later with its default directory
/etc/ssh/ for keys and config files and its default sshd config file
/etc/ssh/sshd_config for the SSH setup of the recovery system.
I removed support for non-standard directories
like /etc/openssh or non-standard sshd config files
like /etc/sshd_config or /etc/openssh/sshd_config.
I documented in the SSH_* section in default.conf
how to manually set up ReaR with a secure shell
software other than OpenSSH >= 3.1.
I removed the incomplete support for CentrifySSH
but did not make OpenSSH mandatory for ReaR
so that the initial problem in
https://github.com/rear/rear/issues/836
does not re-appear (in particular not with SSH_FILES='no').

OliverO2 commented at 2017-10-19 21:56:¶

@jsmeix
I have looked at all the individual commits since my last review of https://github.com/rear/rear/pull/1530. Also looks good to me.

I have also tested the very latest master commit on Ubuntu 16.04 LTS with the default configuration plus SSH_ROOT_PASSWORD. Everything was working fine.

Thank you for lots of hard work, looks pretty complete now! Hope there will be some other test results coming in from people running ReaR on other supported platforms.

jsmeix commented at 2017-10-20 10:07:¶

Via
https://github.com/rear/rear/commit/5985fec78c74f099085f7eca30e60160a022dc44
I simplified the comments in the SSH_ section a bit
to avoid overcomplicated wording as mentioned in
https://github.com/rear/rear/pull/1538#discussion_r145833720

jsmeix commented at 2017-10-20 10:15:¶

@OliverO2
many thanks for your careful review and continuous testing
and even more thanks for your helpful comments that
I needed so much to be able to implement things
where I am not at all an expert.

You really helped a lot to make ReaR both more secure
and even better usable at the same time because now
the SSH config is much more user-friendly:

Unexperienced users just need to set

SSH_ROOT_PASSWORD="rear"

to get remote access to the recovery system
(via a fallback RSA key that is generated during recovery system startup)
and
experienced admins can now specify in detail
what exactly they want regarding SSH.

OliverO2 commented at 2017-10-23 23:09:¶

@jsmeix
Tonight - with some time to let all the details settle - I have again looked at the final result of all SSH changes and it still makes sense to me. The code covers all the important use cases and allows further customization via standard ReaR mechanisms.

It is my impression that the options are pretty simple to use, although the current documentation in default.conf suggests otherwise as it contains more than 100 lines. So I've tried to extract my understanding of how configuration alternatives are meant to be used:

SSH configuration¶

This configuration only affects the rescue system. A system restored by ReaR will receive its SSH configuration entirely from its backup.
ReaR by default supports OpenSSH versions >= 3.1 and SSH files at standard locations.
For a rescue medium free of secrets, just use the default configuration:
- You can access the rescue system's root account via SSH via public/private key if that was permitted on the original system (via authorized_keys).
- Accessing other systems from the rescue system via SSH would require entering a password (as there are no private keys on the rescue medium).
To support added functionality on the running rescue system is possible at the price of having the rescue medium contain secrets:
- To access the rescue system with a password, set SSH_ROOT_PASSWORD.
- To access other systems via root's passphrase-protected SSH private keys present on the original system, set SSH_FILES=y.
- To access other systems via root's protected and unprotected SSH private keys present on the original system, set SSH_FILES=y and SSH_UNPROTECTED_PRIVATE_KEYS=y.
For special needs, you have these options:
- You can specify the SSH configuration files individually by setting SSH_FILES to an array, whose elements are the file paths. Elements of this array receive special key protection if configured.
- You can use COPY_AS_IS to copy more files (without special treatment).
- You can use COPY_AS_IS_EXCLUDE to exclude any SSH file from being copied.

Is that correct and sufficiently complete or did I miss something important?

Maybe the documentation could be streamlined a bit. Hopefully some reasoning that led to the current functionality could be left out. And standard ReaR functionality, such as using REQUIRED_PROGS and LIBS to possibly add support for other SSH versions, could also be left out here. If you think that some details are important, maybe these should go into some kind of migration guide or into the release notes.

jsmeix commented at 2017-10-24 10:26:¶

@OliverO2
many thanks for your review!

Via https://github.com/rear/rear/pull/1543
I simplified the documentation in default.conf according to your
https://github.com/rear/rear/pull/1538#issuecomment-338822611

jsmeix commented at 2017-10-24 14:31:¶

Via
https://github.com/rear/rear/commit/9d2e91c15e6ce0ab897cefd09201f7f64b740f11
I had to re-add what to do when a different secure shell software
is used (other than OpenSSH versions >= 3.1)
plus
the explicit info that with SSH_FILES='no' there is no sshd
in the rescue/recovery system (as requested by @gdha )

[Export of Github issue for rear/rear.]

#1538 PR merged: Only support OpenSSH 3.1 and later for SSH setup¶