BradleyA / docker-security-infrastructure

Automate the generation, setup, check, copy site, host and user docker TLS certificates; Setup and manage dockerd configuration for Ubuntu 16.04 Systemd & Ubuntu 14.04 Upstart. Check ssh permissions
MIT License
17 stars 8 forks source link

ssh notes for design changes #58

Open BradleyA opened 5 years ago

BradleyA commented 5 years ago

Notes about SSH keys in your organization

1 How many SSH keys is your organization using? 2 How many systems they can access? 3 Who uses them? 4 When were they last changed? 5 Do you have a complete list for audits? 6 Where are your SSH keys located? 7 How much access are they providing? 8 Who can use them? 9 Do you limit SSH keys use by location? SSH configurations can restrict the locations from which each authorized SSH key can be used. When access is limited to the known locations of administrators and machine to machine access, it prevents malicious access from other locations. 10 Do you rotate your organization SSH user keys? 11 Who controls the SSH keys at your organization? (key master, key master backup persons)

==> Your organization ends up with thousands of SSH keys that provide access to mission critical systems - all without reviews, rotations, or policy enforcement. Did one of your administrators enable port forwarding on an SSH connection that is approved to traverse through one of your firewalls? This administrative loophole can allow ATT hackers to bypass firewalls.

User configuration of their own authorized SSH keys When you allow user/administrators to control SSH privileged access and when to update keys, you end up with inconsistent security controls, or worse, a compromise of privileged systems or data.

It is time to prioritize SSH management and security using a centralized, automated (?) approach

4 Steps to SSH Security Sound security, policy and auditing practices for SSH keys are required to secure SSH environments. The following four steps will help secure your organization’s SSH usage:

  1. Build a comprehensive inventory. For SSH visibility and control across the network, organizations need centralized visibility into all SSH servers, private keys (the authorized keys that grant SSH access) and any SSH configurations that limit access.
  2. Identify vulnerabilities. To reduce the risk of breach and compromise, organizations must be
BradleyA commented 4 years ago
 https://github.com/BradleyA/sshKeyRotate

Working Principle

The script runs the following sequence:

Generate a new PKA key pair
Copy the public key to the ~/.ssh/authorized_keys file on the remote host (remote directory and file will be created if necessary)
Connect to the remote host using the new private key to assess the validity of the new PKA key pair
Delete all old related public keys in the ~/.ssh/authorized_keys file on the remote host
Copy the new private key to the local ~/.ssh/config file (local directory and file will be created if necessary)
BradleyA commented 4 years ago

Directory design idea on five-rpi3b:

test-directory-structure/
└── uadmin
    └── ssh
        ├── authorized_keys
        ├── one-rpi3b.cptx86.com
        │   ├── uadmin@five-rpi3b.cptx86.com
        │   ├── uadmin@four-rpi3b.cptx86.com
        │   ├── uadmin@six-rpi3b.cptx86.com
        │   ├── uadmin@three-rpi3b.cptx86.com
        │   ├── uadmin@two.cptx86.com
        │   └── uadmin@two-rpi3b.cptx86.com
        ├── six-rpi3b.cptx86.com
        │   ├── uadmin@five-rpi3b.cptx86.com
        │   ├── uadmin@four-rpi3b.cptx86.com
        │   ├── uadmin@six-rpi3b.cptx86.com
        │   ├── uadmin@three-rpi3b.cptx86.com
        │   ├── uadmin@two.cptx86.com
        │   └── uadmin@two-rpi3b.cptx86.com
        └── two-rpi3b.cptx86.com
            ├── uadmin@five-rpi3b.cptx86.com
            ├── uadmin@four-rpi3b.cptx86.com
            ├── uadmin@six-rpi3b.cptx86.com
            ├── uadmin@three-rpi3b.cptx86.com
            ├── uadmin@two.cptx86.com
            └── uadmin@two-rpi3b.cptx86.com