Managing Passwords, SSH Keys, and API Keys Securely

If the credentials that reach your servers and accounts leak, an attacker sails right past every firewall and security group you've set up. Credential hygiene isn't a one-time setup — it's an ongoing habit. Here's how to handle the three types that matter most.

Strong Passwords and a Password Manager

Weak passwords are the number-one reason accounts get brute-forced. Set a few ground rules:

• Favor length — at least 16 characters. Skip birthdays, dictionary words, and anything like admin123.
• Use a unique password for every account, so one breach doesn't cascade.
• Let a password manager (Bitwarden, KeePassXC, 1Password) generate and store them. Never keep them on sticky notes or in plaintext files.
• Turn on two-factor authentication (2FA/TOTP) for critical accounts like your control panel and email.

SSH Keys Beat Passwords

Log in to Linux servers with an SSH key rather than a password whenever you can. Keys are longer, far harder to brute-force, and save you from typing a password every time.

Generate a key pair (ed25519 is a solid default) and protect the private key with a passphrase:

ssh-keygen -t ed25519 -C "[email protected]"
# When prompted "Enter passphrase", set one — don't leave it blank

Install the public key on the server, then log in with the key:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your-server-ip
ssh user@your-server-ip

A few practical rules:

• Use a separate key per machine or purpose — laptop, workstation, CI — so revoking one doesn't disrupt the rest.
• Keep the private key (/.ssh/ided25519) on your own machine only, set its permissions to 600, and never upload or share it.
• Once key login works, disable password login on the server: set PasswordAuthentication no in /etc/ssh/sshdconfig, then run sudo systemctl restart ssh.
• When someone leaves or a device goes missing, revoke promptly: delete that public key's line from /.ssh/authorizedkeys on the server.

Handling API Keys and Tokens

An API key is effectively a programmable password — leak it and someone can call your account directly.

• Never commit them to a code repository. Put keys in environment variables or a dedicated secrets manager (Vault, your cloud provider's Secrets Manager), and exclude .env in .gitignore:

export API_KEY="your-secret-key"
echo ".env" >> .gitignore

• Least privilege: grant a key only the scope it needs. If read-only will do, don't hand it write access.
• Rotate regularly: reissue keys every few months or whenever staff changes, and disable the old ones.
• If a key does slip into Git, rewriting history isn't enough — revoke and reissue it on the provider's side immediately, since it may already have been scraped.

When a Secret Leaks

The moment you suspect a credential is exposed, move fast and in order:

• Revoke or rotate the affected password, key, or token right away so the old one stops working.
• Check your access and audit logs for unexpected logins or API calls.
• Add 2FA to critical accounts and tighten permission scopes.
• Trace how it leaked — an accidental commit, a shared plaintext file, phishing — and close that gap.

Summary

Strong passwords in a password manager guard your accounts; SSH keys with a passphrase, scoped per purpose and revoked on time, replace fragile password logins; API keys live in environment variables or a secrets manager, run on least privilege, rotate on a schedule, and never touch a code repo. When something does go wrong, your first move is always to revoke and rotate — not to wait and hope. Make these habits routine, and you strip away the vast majority of ways your servers and accounts get compromised.