Bugzilla – Bug 1187537
[openssh] installation via ssh - but no permission to passwordlogin as root
Last modified: 2021-06-23 08:58:18 UTC
the openSUSE openssh package recently dropped a patch to be in line with upstream regarding root's ability to login using password (i.e. denied) the openssh change said: - Drop openssh-7.7p1-allow_root_password_login.patch to prevent login as root via password by default (is also upstream default). Comment indicates that this was a temporary meassure that we now had for five years, time to get rid of it (bsc#1173067) If the installation is done over ssh (as is apparently done on all our s390 tests), we see the installation passing (e.g. installation-images had been adjusted to permit root login again), but after reboot, it is no longer possible to connect to the just installed system, as openssh denies logins for root A sample test run: https://openqa.opensuse.org/tests/1797534#step/reconnect_mgmt_console/10
This is interesting, but I'm not really sure what should YaST do? If we are <removing> the old <patch>, then it seems openSUSE does not want to permit root to login by using password. Yes, when the system is being installed over SSH, then it's somehow expected that it should continue to have that option in use. On the other hand, this changes the current security defaults. This looks like a feature to be actually shown in the UI. But UI is too crowded already. Anyway, not that straightforward and security guys should have their word here.
I removed the patch to get password logins denied by default and I would like to keep it this way. We already for a long time offered a weaker default than upstream, which isn't great. Without knowing the details of ssh installs: Isn't it possible to create a key have it persist? If that doesn't work we can consider switching this setting for installs done via ssh, but I would really like to avoid this.
It wouldn't be the first case for me to have the console completely lock up because of X problems (no graphical login, no text consoles) and ssh is the only remaining way to salvage anything. If then the normal user account also doesn't work (NIS problems or home directory not accessible because it's encrypted), a remote root login is the only option that is left (the systemd emergency shell is pretty much unusable for any normal human). This also affects users that we ask to fetch y2logs, so this would make a number of bugs undebuggable. Good luck explaining to such users that they should have done magic things with some ssh key during installation.
It's possible to add an SSH key for root, but it's not enforced and the user does not know that this machine is going to be inaccessible over SSH. Especially if this is the remote-install-method and e.g., the only way to access that machine. It's a change that IMO should have been done through JIRA.
(In reply to Stefan Hundhammer from comment #3) > Good luck explaining to such users that they should have done magic things > with some ssh key during installation. I believe that this is just about remote root login over SSH. This is not about local root login IIUC.
Yes, I was talking about remote root login. That saved my from reinstallation many times. That's why I set a root password even on systems that disable root login in general by not setting one, e.g. Ubuntu.
At first, I was surprised, too. Using ssh keys instead was my first solution in the head. But it makes it all complicated with tests and other things. I thought about another Sysadmin Best Practice for logins (with more steps). Create an additional user besides the root user and give him sudo permissions after the successful installation. That has been done in one past (my first) job as a Sysadmin. Root was not allowed to have any password because of security reasons.
(In reply to Lukas Ocilka from comment #5) > I believe that this is just about remote root login over SSH. This is not > about local root login IIUC. This test reconnect_mgmt_console is failing after trying to login after the restart. It seems that is happening with local root logins, too.
Johannes, we've discussed this with the team and the result is: We all agree that this is not just a "patch removal". It's a feature that has security implications and changes the behavior and expectations from the Installer. But these expectations are absolutely unknown. Changes will also need to be tested and documented. I currently see two options: 1. Revert the patch removal 2. Describe the requested change in JIRA and we can go on that way What is your take here? Thanks in advance.
My 2 cents, if I have any say in this from Leap perspective. 15.4 / 15 SP4 is a feature release, where we have bit more flexibility. With this said, I'd appreciate if we could adopt the more secure default. I'd not touch Leap 15.3 unless SLE decides to apply patch across all supported code-streams. I spent two years of doing health checks, including default sshd_config for various companies in Italy and Portugal and all machines had to be strictly using without-password, no matter the system default. openqa-wise the sooner we do the change in 15.4 / 15 SP4 the better, Beta will set customer expectations. So if we're doing this, then this must be in Alpha phase. I recommend to clone this for Public SLES 15 SP3 product for max-transparency. Cheers. Lubos
Actually JIRA https://jira.suse.com/browse/PM-2745 as per advice of Lukas
So first let me make clear that this change was for Factory only and I don't expect it to be included in SLES 15 (or even older). That would be a change that will cause issues. I'll chime in the Jira for this, but from my POV this will only affect SLES starting with 16 (or whatever will be next). As for the concerns about rescuing a system: Yes, it has drawbacks. But this is just a default that an admin can change if they like. It has been the upstream default for many years and other distributions have picked this up also. I don't think we have issues that are so special that we have to keep carrying this patch that is problematic for security.
Hi all, Given that we already have a Jira entry, I will close this bug and mark it as a feature. Thanks!