Posted inTechnology

SSH Include Password: How to Secure Remote Access with Modular SSH Config

SSH Include Password: How to Secure Remote Access with Modular SSH Config

Configuring SSH for secure remote access often means balancing convenience, security, and maintainability. The phrase “ssh include password” points to two practical ideas at once: using the Include directive to modularize SSH configuration, and handling password authentication in a way that does not compromise security. This article explains how to structure SSH settings with Include, why password authentication should be minimized or eliminated where possible, and how to implement scalable configurations for both servers and clients.

Understanding SSH authentication: keys versus passwords

SSH supports multiple authentication methods, but the two most relevant are public key authentication and password authentication. Key-based authentication is generally stronger when used with a passphrase and an SSH agent. Password authentication, while simpler to set up, is more vulnerable to brute-force attacks, credential phishing, and leaked credentials if servers are exposed to the internet. For most organizations, the recommended baseline is to disable password-based login and rely on key-based access with an agent, while keeping a secure, auditable process for key management.

The Include directive in SSH configuration

OpenSSH provides an Include directive that lets you modularize configuration files. This makes large deployments easier to manage and reduces the risk of misconfiguration. The Include directive can be used in the server config (sshd_config) to pull in additional configuration files from a directory. Files are processed in the order determined by the glob, and last-wins behavior applies for directives that appear in multiple places.

# /etc/ssh/sshd_config
Include /etc/ssh/sshd_config.d/*.conf

Example of a modular approach:

# /etc/ssh/sshd_config.d/01-base.conf
PasswordAuthentication yes
PubkeyAuthentication no

# /etc/ssh/sshd_config.d/02-key-ops.conf
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys

In this arrangement, the final, effective value for PasswordAuthentication would depend on the last included file that defines it. This allows you to maintain a baseline configuration while applying host-specific rules or exceptions in separate files. The strategy is especially useful in environments with many servers, as you can separate policies by role or environment (production, staging, development) and still retain a central control point.

Adopting a secure, scalable workflow with Include

To implement a secure SSH workflow using Include, consider the following steps:

  • Establish a baseline: Create a minimal, secure sshd_config that disables password login by default and enables public key authentication. This reduces surface area for attacks while you deploy keys across hosts.
  • Modularize by role or environment: Use separate files for each role (webserver, database, admin jump host) or environment (prod, staging). Put sensitive or host-specific options in these files.
  • Keep credentials out of files: Do not store passwords in plain text in configuration files. If credentials are needed for automation, use a secrets store or an agent-based approach rather than embedding passwords in config.
  • Audit and test: After adding or changing Include files, reload SSH and test logins from a trusted network. Use verbose SSH client output (ssh -vvv) to verify which settings are applied.
  • Document changes: Maintain a changelog or a small repository describing what each included file controls. This makes it easier for teammates to understand the policy and for audits to verify compliance.

Practical examples: implementing Include and managing password login

Below are practical configurations that illustrate a secure, modular approach. The examples focus on disabling password login on servers while keeping key-based access. They also demonstrate how an included file can alter password-related settings without touching the main file.

# Example: /etc/ssh/sshd_config (baseline)
Port 22
PermitRootLogin prohibit-password
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
UsePAM yes
Include /etc/ssh/sshd_config.d/*.conf

# Example: /etc/ssh/sshd_config.d/10-admin-tools.conf
# This file allows password authentication for a specific admin jump host in a controlled scenario.
# It should be restricted by IP, user, or other criteria in a real deployment.
PasswordAuthentication yes
# Additional admin-specific controls
AllowUsers adminuser

In this setup, the global policy disables password login, but a carefully controlled included file temporarily enables it for a specific, tightly governed role. In practice, you should minimize or eliminate this risk by using keys, strong passphrases, and multi-factor authentication (MFA) where possible.

# Example: /etc/ssh/sshd_config.d/90-key-based.conf
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitRootLogin no

On the client side, you can optimize how you connect to servers that rely on key-based authentication by configuring an SSH client profile. This is not strictly required to use Include, but it helps maintain consistent access patterns across machines.

# ~/.ssh/config
Host prod-web-01
  HostName prod-web-01.example.com
  User deploy
  IdentityFile ~/.ssh/id_rsa
  IdentitiesOnly yes

Host dev-db-1
  HostName dev-db-1.internal
  User admin
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes

With IdentityFile and IdentitiesOnly, you ensure the client presents only the specified keys, reducing the chance that a stray password prompt could appear in automated workflows. The emphasis is on key-based workflows supported by a robust, modular server configuration through Include.

Two-factor authentication and other enhancements

Even with key-based access, you may want to raise the bar with additional security layers. OpenSSH supports methods that can work alongside key-based authentication to provide stronger assurance:

  • Two-factor authentication (2FA): Combine public keys with keyboard-interactive or other second factors. For example, you can configure AuthenticationMethods as a combination of publickey and keyboard-interactive to require both a valid key and a one-time password.
  • Use PAM with care: If you enable PAM, you can integrate SSH with an enterprise authentication system, but ensure PAM modules are hardened and audited. Consider disabling password prompts in favor of MFA wherever feasible.
  • Rate limiting and brute-force defense: Use tools like fail2ban or similar to monitor login attempts and block abusive sources. This reduces risk even if some password-based paths exist.
  • Logging and auditing: Enable verbose logging for authentication events and centralize logs for monitoring. This is essential to detect suspicious login patterns early.

Common pitfalls and how to avoid them

  • Mixing policies without clarity: If you enable PasswordAuthentication in one included file and disable it in another, the final result depends on the order of includes. Maintain a clear policy and test login behavior after changes.
  • Forgetting to restart or reload: After changing sshd_config or any included files, reload or restart the SSH daemon to apply changes. A failed reload could lock you out if you’re connected remotely.
  • Not validating permissions: SSH configuration files should be readable by root and not writable by non-privileged users. Ensure file permissions are strict (e.g., 600 for sensitive files).
  • Overcomplicating the setup: Modularization should simplify maintenance, not create a web of exceptions. Start with a straightforward baseline and add complexity only when justified by operational needs.

Testing and validation

Testing is a critical step before deploying changes to production systems. Some practical checks include:

  • Test from a trusted client: Open a terminal from a workstation that has the appropriate key loaded in the agent or a configured client profile. Attempt to log in to a test host using SSH in verbose mode to observe which directives apply.
  • Check server logs: Review /var/log/auth.log or equivalent to confirm which authentication methods were used and whether the login succeeded or failed.
  • Verify fallback behavior: If you disable password login, ensure there is at least one functional key-based path, or you could lose access.

Conclusion: secure, maintainable SSH with Include and thoughtful password management

Modular SSH configuration via the Include directive offers a structured way to manage complex environments. By combining this approach with a strong preference for key-based authentication and a careful stance toward password-based access, you can achieve secure, scalable remote administration. Remember to document your policy, test thoroughly, and layer in additional protections such as MFA, monitoring, and rate limiting as part of a holistic security posture. When done well, the result is a robust SSH setup that remains maintainable across dozens or hundreds of hosts while minimizing the risks associated with password-based login.