ssh notes for design changes

[BradleyA]

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]

 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]

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