4 ms·

I like to do "PermitRootLogin no" as well, but I guess it's not really necessary if one uses some of the other config you've given.

thaumaturgy 11y ago
IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root-login-via-ssh/ https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...
- protomyth 11y ago
  Just got set to the default on OpenBSD, so it should be shipped in 5.8.
- anonova 11y ago
  I was curious, so I checked different distros. Debian-based distros set `without-password`, and others use the default `no`. * Arch Linux (openssh-6.9p1-1): #PermitRootLogin no * CentOS 7 (openssh-server 6.6.1p1-12.el7_1): #PermitRootLogin yes * Debian 8.1 (openssh-server 1:6.7p1-5): PermitRootLogin without-password * Fedora 22 (openssh-server 6.9p1-2.fc22): #PermitRootLogin yes * openSUSE 13.2 (openssh 6.6p1-5.1.3): #PermitRootLogin yes * Ubuntu 14.04.2 (openssh-server 1:6.6p1-2ubuntu1): PermitRootLogin without-password * Ubuntu 15.04 (openssh-server 1:6.7p1-5ubuntu1): PermitRootLogin without-password
  - deleted 11y ago
    [deleted]
  - deleted 11y ago
    [deleted]
  - scintill76 11y ago
    Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.) I looked into OpenSSH's commit history ([2],[3],[4],[5]) and it looks like some waffling and/or release-process side-effects resulted in the man page in 6.9 saying the default is "no", but the actual code retaining "yes" (confirmed in the portable 6.9p1 tarball). I kind of hope I'm wrong somehow; this is a bit disturbing. [1] http://www.openssh.com/txt/release-6.9 http://www.openssh.com/txt/release-6.9 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a94ff53f76df228eeaae238d2d467565 https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed670f516652eeba50705e1e9f6325346 https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8551b471fcae0447c1d78464f6dba869 https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6e4071d454b72927ffaf52949fa34545 https://github.com/openssh/openssh-portable/commit/7de4b03a6...
    - anonova 11y ago
      Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros. So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`." Thanks for the correction!
      - scintill76 11y ago
        Thanks for the reply. On editing, I'm not sure exactly how it works, but posts on HN become uneditable at some point. I came across this post[1] and bug comment[2]. If I'm understanding correctly, Red Hat will not follow the OpenBSD upstream on this! So I would guess CentOS and Fedora will also keep allowing root login, with password, by default. [1] https://lists.fedoraproject.org/pipermail/package-announce/2015-July/161692.html https://lists.fedoraproject.org/pipermail/package-announce/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26 https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26
chmielewski 11y ago
The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being checked into.
- scintill76 11y ago
  I would say auditability is still security-related, but yes, this is good practice too. You should probably also make sure root has a locked password, so that things other than SSH won't allow root login.

thaumaturgy 11y ago

IIRC I think "PermitRootLogin no" is now the default on most distributions. Debian at least: https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root-login-via-ssh/ https://debiantalk.wordpress.com/2015/04/27/debian-8-no-root...

protomyth 11y ago
Just got set to the default on OpenBSD, so it should be shipped in 5.8.
anonova 11y ago
I was curious, so I checked different distros. Debian-based distros set `without-password`, and others use the default `no`. * Arch Linux (openssh-6.9p1-1): #PermitRootLogin no * CentOS 7 (openssh-server 6.6.1p1-12.el7_1): #PermitRootLogin yes * Debian 8.1 (openssh-server 1:6.7p1-5): PermitRootLogin without-password * Fedora 22 (openssh-server 6.9p1-2.fc22): #PermitRootLogin yes * openSUSE 13.2 (openssh 6.6p1-5.1.3): #PermitRootLogin yes * Ubuntu 14.04.2 (openssh-server 1:6.6p1-2ubuntu1): PermitRootLogin without-password * Ubuntu 15.04 (openssh-server 1:6.7p1-5ubuntu1): PermitRootLogin without-password
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- scintill76 11y ago
  Thanks for checking, but I'm not sure you're correct. AFAICT setting the default to "no" is not due for official release until later this month[1]. Maybe some of the distros are patching the upstream default directly in their source (seems bad idea to me), but I at least checked the CentOS version you referenced and it appears to default to "yes" in the source (and the config excerpt you cited is commented out.) I looked into OpenSSH's commit history ([2],[3],[4],[5]) and it looks like some waffling and/or release-process side-effects resulted in the man page in 6.9 saying the default is "no", but the actual code retaining "yes" (confirmed in the portable 6.9p1 tarball). I kind of hope I'm wrong somehow; this is a bit disturbing. [1] http://www.openssh.com/txt/release-6.9 http://www.openssh.com/txt/release-6.9 [2] https://github.com/openssh/openssh-portable/commit/88a7c598a94ff53f76df228eeaae238d2d467565 https://github.com/openssh/openssh-portable/commit/88a7c598a... [3] https://github.com/openssh/openssh-portable/commit/d921082ed670f516652eeba50705e1e9f6325346 https://github.com/openssh/openssh-portable/commit/d921082ed... [4] https://github.com/openssh/openssh-portable/commit/47aa7a0f8551b471fcae0447c1d78464f6dba869 https://github.com/openssh/openssh-portable/commit/47aa7a0f8... [5] https://github.com/openssh/openssh-portable/commit/7de4b03a6e4071d454b72927ffaf52949fa34545 https://github.com/openssh/openssh-portable/commit/7de4b03a6...
  - anonova 11y ago
    Ah, you're right. I read sshd_config(5) on Arch, which uses 6.9p1 and says the incorrect default is "no". I assumed this was the case on other distros. So to correct my previous post (I can't seem to edit?), it should be, "Debian-based distros set `without-password`, and others use the default `yes`." Thanks for the correction!
    - scintill76 11y ago
      Thanks for the reply. On editing, I'm not sure exactly how it works, but posts on HN become uneditable at some point. I came across this post[1] and bug comment[2]. If I'm understanding correctly, Red Hat will not follow the OpenBSD upstream on this! So I would guess CentOS and Fedora will also keep allowing root login, with password, by default. [1] https://lists.fedoraproject.org/pipermail/package-announce/2015-July/161692.html https://lists.fedoraproject.org/pipermail/package-announce/2... [2] https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26 https://bugzilla.redhat.com/show_bug.cgi?id=89216#c26

chmielewski 11y ago

The reason for this isn't security-related, if you've followed the steps above and have applied them to root. The reason to not allow root login is so that each of multiple administrators must login using their username and then become root or use sudo. That way if you look to see who did what, you get a username rather than "root did that". Which, of course, you usually need root to do things that end up being checked into.

scintill76 11y ago
I would say auditability is still security-related, but yes, this is good practice too. You should probably also make sure root has a locked password, so that things other than SSH won't allow root login.