Is allowing root login in SSH with "PermitRootLogin without-password" a secure method?

  • I have set my live IP in /etc/hosts.allow, and deny all other hosts. I have also set PermitRootLogin without-password in /etc/ssh/sshd_config.

    Is that a secure method? Can an attacker crack my key and login to my server? If yes then please explain how it is possible.

    Not sure (I wasn't the one who downvoted). I imagine it may be an issue with it being yet another "is this secure?" question, especially one where it's pretty easy to find the answer on Google.

    One of the reasons why someone might downvote is because of "lack of research effort". Reading the documentation for PermitRootLogin will answer half of your question. The other half "Can attacker crack key and login my server?" is a completely different question.

  • This is a common misunderstanding for the PermitRootLogin feature. The without-password option does not mean there is no authentication and anyone can get in without a password. All this option means is that logging in is only possible using a fallback method, such as public key authentication. Even if an attacker knows your root password, they will not be able to log in unless they have your private key.

    It is actually better to use without-password if you need to log in as root, since it ensures that the root account cannot be brute forced. If you were to log in as root with a password, it could be subject to being remotely attacked, whereas public key authentication ensures you can only log in with the proper credential files. This is better than logging in as a different user and using su to elevate to root, as a compromise of that other user would result in a compromised root, since the user can monitor any keystrokes entered into its shell. This is explained in detail in the answer to Which is the safest way to get root privileges: sudo, su or login?.

    If you do not need to have root, then using another, dedicated user would be fine. In this case, setting PermitRootLogin no would be beneficial, as there is no reason to have root access if not required.

    This answer is spot on and in detail, should be the accepted answer @LOKESH

  • First let's see what does it mean:


    Specifies whether root can log in using ssh(1). The argument must be “yes”, “without-password”, “forced-commands-only”, or "no”. The default is “yes”.

    If this option is set to “without-password”, password authentication is disabled for root. If this option is set to “forced-commands-only”, root login with public key authentication will be allowed, but only if the command option has been specified (which may be useful for taking remote backups even if root login is normally not allowed). All other authentication methods are disabled for root.

    If this option is set to “no”, root is not allowed to log in.

    Better practice is to use PermitRootLogin no, because you don't want to allow root to directly authenticate into the system.

    That is a dangerous practice to promote, considering logging in as another user and elevating yourself to root from it gives that user way too much power.

    If I use my live ip in /etc/hosts.allow then how attack can be done?

    The `/etc/hosts.allow` is useful for an additional layer of protection, but it must not be relied on for authentication. You do not want someone who is able to pivot through your computer or your ISP, or even just get your old IP when it switches (e.g. with dynamic IPs) to be able to access your server.

  • Yes it's a secure method because you can't brute force cryptographic key.

    For example if you use a RSA key (ssh-keygen -t rsa)

    The only solution for the hacker is to steal your private/public keys.

    That's not a good reference for saying RSA is secure. It talks about a very specific way of trying to break RSA (enumerating all primes of a certain size), but there are much _much_ better ways to attack RSA (ie factoring). The answer is also talking about 1024 bit keys, which NIST recommended deprecating by 2013. While no 1024 bit keys have been (publicly) broken yet, using one at this point is very questionable.

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used