Dear all, I think there is a unsafe setting in the /etc/sshd_config file. The following setting is be done: PermitRootLogin yes. It think it would be best to change the yes to no. This is to make it more difficult for a hacker. Regards, Joop Boonen. Can this please also be changed in the rpm package?
Dear all,
I think there is a unsafe setting in the /etc/sshd_config file. The following setting is be done: PermitRootLogin yes. It think it would be best to change the yes to no. This is to make it more difficult for a hacker.
Regards,
Joop Boonen.
Can this please also be changed in the rpm package?
Joop, the rationale behind this is that it should be possible to log on to a freshly installed machine in some way. Since the root account is the only one upon completion of the installation to have a valid password, the setting is "yes". If there should be any remote access after a fresh installation at all, then it is considered safest to use ssh. Please note that the settings include PermitEmptyPasswords no # in both openssh and ssh which means that the admin is protected against himself in terms of passwords related to remote logins. Anything more would be uncivilized. Please disable the option on your own if you feel uncomfortable with it. I bet that thousands of users would complain if this detail is changed. Regards, Roman. -- _ _ | Roman Drahtmüller "Freedom means that you can choose | CC University of Freiburg what you want to learn at a given | email: draht@uni-freiburg.de time." A. Becker, 1999 | - - People often find it easier to be a result of the past than a cause of the future.
the rationale behind this is that it should be possible to log on to a freshly installed machine in some way. Since the root account is the only one upon completion of the installation to have a valid password, the setting is "yes". If there should be any remote access after a fresh installation at all, then it is considered safest to use ssh.
Please note that the settings include PermitEmptyPasswords no # in both openssh and ssh
which means that the admin is protected against himself in terms of passwords related to remote logins. Anything more would be uncivilized.
Please disable the option on your own if you feel uncomfortable with it. I bet that thousands of users would complain if this detail is changed.
What is confusing is the rc.config setting ROOT_LOGIN_REMOTE. It only covers telnet, which no sane security minded person would use anyway. The comments does not indicate this however, so one might think that no remote login was possible at all when this is set to "no", very ufortunate! It would seem logical to let ROOT_LOGIN_REMOTE affect all kinds of remote shells, if possible, or at least put a comment on it that it only affects telnet. Regards, Simon Lodal
What is confusing is the rc.config setting ROOT_LOGIN_REMOTE. It only covers telnet, which no sane security minded person would use anyway. The comments does not indicate this however, so one might think that no remote login was possible at all when this is set to "no", very ufortunate!
It would seem logical to let ROOT_LOGIN_REMOTE affect all kinds of remote shells, if possible, or at least put a comment on it that it only affects telnet.
Regards,
Simon Lodal
You're right, the fact deserves at least a comment in /etc/rc.config. But if you claim that a password authentication scheme is insecure even if protected communication channels (console, ssh, ...) are being used, then why would you use password authentication methods in the first place? (Passwords are useless if you don't honor the secret they provide.) ROOT_LOGIN_REMOTE is window-dressing anyway, unless you decline logins of ordinary users as well. The use of `su -' succeeding a login using a plaintext protocol and password authentication is even worse, revealing _two_ passwords. (I wonder who do we protect ourselves against...) From this standpoint, it might make sense to abolish the ROOT_LOGIN_REMOTE mimics completely and replace it with a general ALLOW_LOGIN_REMOTE and/or PLAINTEXT_LOGIN_REMOTE, effectual for all users of the system in question by disabling all unencrypted login options. To me, this approach is more modern than the other ones. Again, taste may vary... There still remains the legal problem with cryptography in some countries. But interesting legislative development is in sight... Roman. -- _ _ | Roman Drahtmüller "Freedom means that you can choose | CC University of Freiburg what you want to learn at a given | email: draht@uni-freiburg.de time." A. Becker, 1999 | - - People often find it easier to be a result of the past than a cause of the future.
Dear all, Maybe it would be best that the no root log in will change the setting for ssh and rsh to? Via yast that is, and SuSEconfig. I think that would be a good move. Regards, Joop Boonen. Simon Lodal wrote:
the rationale behind this is that it should be possible to log on to a freshly installed machine in some way. Since the root account is the only one upon completion of the installation to have a valid password, the setting is "yes". If there should be any remote access after a fresh installation at all, then it is considered safest to use ssh.
Please note that the settings include PermitEmptyPasswords no # in both openssh and ssh
which means that the admin is protected against himself in terms of passwords related to remote logins. Anything more would be uncivilized.
Please disable the option on your own if you feel uncomfortable with it. I bet that thousands of users would complain if this detail is changed.
What is confusing is the rc.config setting ROOT_LOGIN_REMOTE. It only covers telnet, which no sane security minded person would use anyway. The comments does not indicate this however, so one might think that no remote login was possible at all when this is set to "no", very ufortunate!
It would seem logical to let ROOT_LOGIN_REMOTE affect all kinds of remote shells, if possible, or at least put a comment on it that it only affects telnet.
Regards,
Simon Lodal
--------------------------------------------------------------------- To unsubscribe, e-mail: suse-security-unsubscribe@suse.com For additional commands, e-mail: suse-security-help@suse.com
participants (3)
-
Joop Boonen -
Roman Drahtmueller -
Simon Lodal