DevOps

Passwords & SSH Keys

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron

Passwords

  • username
  • identification
  • password
  • authentication
  • AuthN

Problems with Passwords

  • Length
  • Are typically not random
  • Password reuse
  • Unable to specify overall strength

Solutions (?)

  • Maximum Length Restrictions Limit passwords to a short maximum length, such as 8 or 16 characters.
  • No Special Characters Allowed Restrict the use of some special characters.
  • Case Insensitivity Treat passwords as case-insensitive, meaning that "Password123" and "password123" would be considered the same.
  • Forced Inclusion of Certain Character Types Require a mix of uppercase letters, lowercase letters, numbers, and special characters. Rules can be overly specific, e.g., one of each but no more than two of any category.
  • Prohibition of Sequential or Repeated Characters Do not allow more than two sequential (e.g., "123" or "abc") or repeated (e.g., "111" or "aaa") characters.
  • Regular Mandatory Changes Without Reuse Enforce password changes every few months but prevent the reuse of any of the last dozen or more passwords. This can lead users to create weaker passwords or variations of previous passwords, potentially reducing security over time.

Problems with Passwords

  • Length requirements
  • Composition requirements
  • Password expiration
  • Leads to productivity impact, password sequences, writing them down,
  • These are not guaranteed solutions

Professionals

  • Consider Computer Science graduates, Software Engineers, and DevOps Engineers to be professionals
  • These jobs use computers for all aspects, and what you do can affect others
  • Insecure work on servers has security implications for users of the server
  • Insecure development has implications for what is in the code
  • Computer security is important
  • Use good practices in all your work
  • Remember that good practices change over time

Password Good Practices

  • Long
  • Use proven techniques, e.g., diceware
  • Do not reuse between sites
  • Use a password manager

Password Managers

  • 1Password, Bitwarden
  • master password - make highly secure and memorable
  • e.g., 6-word diceware, or even 7
  • Password generator built-in
  • Relatively easy to have a unique password for every site
  • Some even manage SSH keys

Other Password Problems

  • Require a password stored on each server
  • How to include in software-to-software communication?

SSH Keys

  • A non-password way to communicate securely over a network
  • Basis of certificates and other software-to-software communications

SSH Key Advantages

  • Length
  • Built into, and guaranteed by, key type
  • Ease of Use
  • Length and complexity require storing in a file
  • Management of keys part of the generation and use
  • Security
  • Public-key systems are very reliable
  • Only the public key is shared; the private key remains private
  • Flexibility
  • Can be used by people
  • Can be used by software

SSH Key Types

  • RSA - integer factorization, deprecated
  • DSA - finite fields, deprecated
  • ECDSA
  • ed25519 - Uses prime 2255 - 19, current best choice

Generating Keys

  • ssh-keygen
  • -t Type of key: rsa, dsa, ecdsa, ed25519
  • -b (RSA, DSA) Number of bits and not needed for ed25519
  • -o Save the private key using the OpenSSH format PEM format (default for ed25519)
  • -a Number of KDF (Key Derivation Function) rounds
  • Higher: slower passphrase verification
  • Higher: Increase resistance to brute-force cracking
  • -f Filename of generated key file (default based on key type)
  • -C Comment, purely informational, typically login@hostname (by default)

SSH Key Generation Good Practice

  • Key type: ed25519
  • KDF: 100
  • For an ed25519 key:
  • ssh-keygen -t ed25519 -a 100
  • For an RSA key (for use on older systems):
  • ssh-keygen -t rsa -b 4096 -o -a 100
  • For now, we will use an empty passphrase

Key Management Options

  • One SSH key per user
  • One SSH key per local machine, e.g., one for your laptop, one for your desktop
  • One SSH key per user per domain, e.g., cs.uakron.edu
  • One SSH key per user per machine you log into, e.g., one SSH key for every server
  • Will look at key pass through, i.e., ssh agent forwarding, which helps this problem
  • e.g., Local keys for local->s1 and local->s2, allows local->s1->s2