Fix SSH root login on the recovery system with some configurations

[OliverO2]

Pull Request Details:

• Supercedes: Fix SSH root login on the recovery system with some configurations #2068

• Type: Bug Fix

• Impact: High (cannot log in via SSH on rescue system)

• Reference to related issue (URL):

• How was this pull request tested? On Ubuntu 18.04.2 LTS

• Brief description of the changes in this pull request:

On Ubuntu 18.04 with OpenSSH 7.6, /etc/ssh/sshd_config contains
commented-out lines for 'PermitRootLogin' and other options. This fix
makes sure that settings changed for ReaR will be real, not comments.

[jsmeix]

Looks good to me:

# echo -e '# PermitRootLogin foo\n # bar ClientAliveInterval baz' | sed -e 's/.*PermitRootLogin.*/#&/' -e '$ a PermitRootLogin yes' -e 's/.*ClientAliveInterval.*/#&/' -e '$ a ClientAliveInterval 0'

## PermitRootLogin foo
# # bar ClientAliveInterval baz
PermitRootLogin yes
ClientAliveInterval 0

Because usr/share/rear/skel/default/etc/scripts/run-sshd
modifies /etc/ssh/sshd_config only in ReaR's own recovery system
any modifications that make things work there are ok.

[jsmeix]

@gdha or any other @rear/contributors
could you also have a look if this change is ok.

If there are no objections I would like to merge it tomorrow.

@OliverO2
what about when there is no /etc/ssh/sshd_config in the recovery system?
As far as I see the sshd config file gets copied into the recovery system
via different kind of copy_as_is_ssh_files=( ... ) settings in
usr/share/rear/rescue/default/500_ssh.sh
but - on first glance - I see nothing that verifies there is actually a
/etc/ssh/sshd_config file in the recovery system.

In gereral COPY_AS_IS ignores non existent files and I think
that behaviour is often used in ReaR by adding lots of stuff
to COPY_AS_IS like

COPY_AS_IS=( "${COPY_AS_IS[@]}" something something_else )

to get 'something' and/or 'something_else' into the recovery system
depending on what there is on the original system, e.g. with

COPY_AS_IS=( "${COPY_AS_IS[@]}" QQQ )

"rear mkrescue" just works fine - QQQ is silently ignored
unless one inspects the log file where one gets

+ source /root/rear.github.master/etc/rear/local.conf
...
++ COPY_AS_IS=("${COPY_AS_IS[@]}" QQQ)
.
.
.
+ source /root/rear.github.master/usr/share/rear/build/GNU/Linux/100_copy_as_is.sh
...
++ test -f 'tar: QQQ: Cannot stat: No such file or directory'

[OliverO2]

@jsmeix

what about when there is no /etc/ssh/sshd_config in the recovery system?

usr/share/rear/skel/default/etc/scripts/run-sshd would fail altogether if there is no sshd. And if there is an sshd we can safely assume that /etc/ssh/sshd_config exists, as it is a required configuration file. sshd exits with an error message if the file cannot be opened.

So basically, run-sshd would fail one way or the other if the original system did not provide a complete openssh installation.

[jsmeix]

@OliverO2
thank you for your explanation!

[jsmeix]

@OliverO2
thank you for continuously testing ReaR
and for your analysis plus your bug fix!