Security hardening

centos_disable_password_ssh.sh

Built for CentOS and similar OpenSSH hosts that should move from password-based login to key-only access. The script refuses to proceed unless the target user has a non-empty authorized_keys file, then updates sshd_config and validates the result before reloading the daemon. A non-empty file does not prove that the operator has the matching private key.

One-liner

curl -fL 'https://www.helper.sh/centos_disable_password_ssh.sh' -o './centos_disable_password_ssh.sh'

This command downloads the bundled file only; it does not run it. Inspect the saved source and compare its version before deciding whether to execute it.

Check the file you downloaded

Compare a saved file with the exact bytes bundled in this page’s build. The file stays in this tab; this tool does not upload or persist it. Maximum 2 MiB.

Expected SHA-256
8605b22d876f2d661cfb54990bdf634a9505cb55f00653d471358085db4e627e

Bundled byte count: 2874

Save checksum file

Save the script and checksum in the same directory. On Linux with GNU Coreutils, the command below checks the saved bytes only; it does not run the script. Keep the original filename for this command.

sha256sum --check './centos_disable_password_ssh.sh.sha256'

No comparison yet.

The checksum and script come from the same site, not an independent signature. A match does not prove safety, authenticity of upstream dependencies, or suitability for your host. Mutable remote dependencies need separate review.

Read validation and limitations

Requirements

  • CentOS or similar OpenSSH host
  • root privileges or sudo
  • A non-empty authorized_keys file for the target user
  • /etc/ssh/sshd_config present

Best for

  • Disable SSH password login after key-based access is ready
  • Standardize key-only hardening on CentOS maintenance tasks
  • Reduce brute-force password attack surface on exposed SSH hosts

Highlights

  • Fails fast if the target user does not already have authorized_keys
  • Uses idempotent sshd_config edits instead of blind string appends
  • Restores the original config automatically if sshd -t fails

Recommended procedure

  1. Ensure your SSH public key is already installed for the target user.
  2. Fetch the script from helper.sh and run it with sudo or as root.
  3. Let the script update sshd_config, validate it, and reload sshd.
  4. Open a second SSH session and verify key-based login still works before closing the first session.

Safety notes

  • Do not run this script before verifying key-based SSH access from another terminal.
  • Set TARGET_USER=<name> if the authorized_keys file belongs to a non-root account.
  • The script leaves UsePAM enabled to avoid unnecessary session handling regressions.

Compatibility and limits

  • For CentOS or similar OpenSSH systems using the `sshd` service; requires root, getent, cut, sshd -t, and systemctl or service. The only input is TARGET_USER; it defaults to SUDO_USER, then root. There is no dry-run.
  • The preflight checks only that the selected user's ~/.ssh/authorized_keys file is non-empty. It does not validate key syntax or prove that the operator has the matching private key. Do not use until a separate key-based login has succeeded.
  • The script edits /etc/ssh/sshd_config only; it does not inspect included files. A syntax failure restores the backup automatically, but if reload and restart both fail after validation, the new file remains in place.

Files, services, and data affected

  • /etc/ssh/sshd_config: sets PubkeyAuthentication yes and AuthorizedKeysFile .ssh/authorized_keys; disables PasswordAuthentication, KbdInteractiveAuthentication, and ChallengeResponseAuthentication; keeps UsePAM yes.
  • Creates a timestamped /etc/ssh/sshd_config.bak.* copy before edits. Reloads sshd, with restart as fallback. Does not edit authorized_keys, user passwords, firewall ports, or application data.

Read-only verification

  • Before any change, check the selected account and its home with `getent passwd USER`, then confirm the corresponding `.ssh/authorized_keys` is non-empty and test key login from a second terminal.
  • Inspect effective settings read-only with `sudo sshd -T | grep -E '^(pubkeyauthentication|authorizedkeysfile|passwordauthentication|kbdinteractiveauthentication|challengeresponseauthentication|usepam) '`.
  • After an authorized maintenance run, check `sudo sshd -t`, `sudo systemctl status sshd` (or `sudo service sshd status`), and test a new key login. Keep the original session open until that succeeds.

If it fails

If preflight fails, the script makes no config change. If sshd -t fails, it copies the saved backup over sshd_config. If both reload and restart fail, keep the current session open, inspect `sudo journalctl -u sshd -n 100 --no-pager`, restore the timestamped backup manually if appropriate, validate with `sudo sshd -t`, and recover the service before closing the session.

Reference documentation

The CentOS 7 manual archive is served by a mirror. The current OpenBSD manual is upstream reference material and may differ from the version shipped with CentOS 7.

Download, inspect, then verify the version before execution. A hash only identifies these exact bytes; it does not prove safety. Piped commands run remote content immediately, and upstream dependencies can change.

Related topics

CentOS 7: choose a recovery task

Separate repository failures, SSH access problems and Docker storage pressure before changing an end-of-life host.

Open topic

Problem pages

Why can I not connect after disabling SSH password login on CentOS

The usual cause is disabling PasswordAuthentication before confirming that the target account already has a working authorized_keys file and a successful key-based login test.

Open page