SSH Security: Does PermitRootLogin=yes behave like prohibit-password when PasswordAuthentication=no?


36 views

In SSH server configurations, two critical directives often cause confusion when used together: PermitRootLogin and PasswordAuthentication. Let's examine their interaction through practical examples.

# /etc/ssh/sshd_config example
PasswordAuthentication no
PermitRootLogin yes
PubkeyAuthentication yes

When PasswordAuthentication is set to no, the server completely disables password-based authentication. This means:

  • All authentication attempts must use public keys or other non-password methods
  • The prohibit-password option in PermitRootLogin becomes redundant
  • Root login attempts without valid keys will fail regardless of PermitRootLogin setting

While the effective security is identical in this configuration, setting PermitRootLogin prohibit-password provides additional benefits:

# Recommended configuration for clarity
PasswordAuthentication no
PermitRootLogin prohibit-password

This combination explicitly documents the security intent and prevents potential issues if PasswordAuthentication gets accidentally enabled later.

Here's how we audit and enforce these settings across our server fleet using Ansible:

- name: Ensure secure SSH configuration
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: "^{{ item.regexp }}"
    line: "{{ item.line }}"
    state: present
  with_items:
    - { regexp: '^PasswordAuthentication', line: 'PasswordAuthentication no' }
    - { regexp: '^PermitRootLogin', line: 'PermitRootLogin prohibit-password' }
  notify: restart sshd

Special scenarios where the distinction matters:

  1. When using PAM authentication modules that might bypass PasswordAuthentication
  2. When other authentication methods (like Kerberos) are enabled
  3. During security audits where explicit configurations are required

In these cases, keeping prohibit-password provides an additional security layer.

In enterprise environments, balancing security with operational requirements often leads to nuanced SSH configurations. The interaction between PermitRootLogin and PasswordAuthentication directives creates important security implications that aren't always immediately obvious from the documentation.

# Example from /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin yes  # Our focal point

When PasswordAuthentication no is set, the server completely disables password-based authentication for all users. This fundamentally alters how PermitRootLogin yes behaves in practice:

  • With password auth enabled: PermitRootLogin yes allows both password and key-based root access
  • With password auth disabled: It effectively only permits key-based root access

Consider these practical scenarios:

# Scenario 1: Explicit key-only root access
PermitRootLogin prohibit-password
PasswordAuthentication no

# Scenario 2: Implicit key-only root access
PermitRootLogin yes
PasswordAuthentication no

Both configurations achieve the same security posture regarding root access, but the second one might confuse auditors or future administrators who don't notice the password authentication setting.

While functionally equivalent in this specific context, there are operational differences:

Consideration prohibit-password yes (with password auth off)
Explicit intent Clear Ambiguous
Audit clarity High Medium
Future-proofing Better Worse

For production systems, I recommend:

# Best practice configuration
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey

This combination provides maximum clarity and defense in depth, even though PermitRootLogin yes would technically be equally secure when paired with disabled password authentication.

Consider these additional security measures for root access:

# Additional hardening
Match User root
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no
    PermitTunnel no

These restrictions complement your root login policy by limiting what authenticated root sessions can do.