#2070 PR `merged`: Fix SSH root login on the recovery system with some configurations¶

Labels: bug, fixed / solved / done

OliverO2 opened issue at 2019-03-06 15:36:¶

Pull Request Details:¶

Supercedes: https://github.com/rear/rear/pull/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 commented at 2019-03-07 09:53:¶

@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 commented at 2019-03-07 10:52:¶

@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 commented at 2019-03-07 12:10:¶

@OliverO2
thank you for your explanation!

jsmeix commented at 2019-03-08 12:40:¶

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

[Export of Github issue for rear/rear.]

#2070 PR merged: Fix SSH root login on the recovery system with some configurations¶