Secure Node Access: SSH Key Management Configuration

Securing access to your nodes is paramount, and in this comprehensive guide, we'll walk you through configuring SSH key management for robust security. Let's dive into the world of secure connections!

Task: Configuring SSH Key Management for Node Access

Phase: 1 - Docker Infrastructure

Priority: High

Estimated Effort: 1-2 hours

Description

The primary goal here is to set up SSH key management so that our Docker container can securely connect to OpenWrt nodes for deployment. This encompasses several crucial steps, including SSH key generation, proper mounting of keys, setting appropriate permissions, and thorough documentation. We aim to create a secure and efficient workflow for node access.

Why SSH Keys?

Before we delve into the implementation details, let's briefly discuss why SSH keys are the preferred method for secure access. Unlike passwords, which can be susceptible to brute-force attacks and interception, SSH keys offer a much stronger security posture. SSH keys rely on cryptographic key pairs – a private key (which you keep secret) and a public key (which you place on the server you want to access). This method ensures that only authorized users with the correct private key can gain access, making it significantly harder for attackers to compromise your systems.

Key Components of SSH Key Management

Our configuration will involve several key components:

1. Key Generation: We'll explore methods for generating secure SSH key pairs, ensuring that the private key remains confidential.
2. Mounting Keys: We'll set up the Docker container to correctly mount the SSH keys, making them available for secure connections.
3. Permissions: We'll configure file permissions to safeguard the private key, preventing unauthorized access.
4. Documentation: Comprehensive documentation will guide users through the setup process and address potential issues.

Acceptance Criteria

To ensure that our SSH key management configuration is successful, we'll adhere to the following acceptance criteria:

• [ ] SSH key generation documented: Clear instructions for generating SSH keys will be readily available.
• [ ] Keys mounted correctly in the container: The Docker container must be able to access the SSH keys.
• [ ] Proper file permissions (600 for the private key): The private key's permissions must be restricted to the owner for security.
• [ ] Container can SSH to nodes (if accessible): The container should be able to establish SSH connections to the target nodes.
• [ ] Instructions for key setup in docker/README.md: A dedicated section in the docker/README.md file will outline the SSH key setup process.
• [ ] Security best practices followed: Our configuration will align with industry-standard security practices.
• [ ] Alternative methods documented (password, existing keys): Alternative access methods, like password-based authentication or using existing keys, will be documented for flexibility.

Implementation Details

Let's delve into the nitty-gritty details of how we'll implement SSH key management.

• Location: All relevant documentation will reside in the docker/README.md file, serving as a central resource for users.
• Dependencies: This task depends on #2 (docker-compose.yml with volume mount), ensuring that the necessary infrastructure is in place.
• Security: We'll emphasize that SSH keys must never be committed to the repository, as this would expose sensitive information.

SSH Key Setup Options

We'll provide users with several options for setting up SSH keys, catering to different preferences and scenarios.

Option 1: Leveraging Existing SSH Keys (Recommended)

If you already have SSH keys, this option is the most straightforward. The docker-compose.yml file is pre-configured to mount keys from ~/.ssh:/root/.ssh:ro, meaning your existing keys will be automatically available within the container. No action is needed if your keys are already in place.

# Keys automatically mounted from ~/.ssh/
# docker-compose.yml already includes:
#   - ~/.ssh:/root/.ssh:ro

# No action needed if keys already exist

Option 2: Generating New SSH Keys for Mesh Deployment

For those who prefer a dedicated set of SSH keys for mesh deployment, this option outlines the steps for generating a new key pair.

# Generate new SSH key pair
ssh-keygen -t ed25519 -C "mesh-deployment" -f ~/.ssh/mesh_deployment_ed25519

# Copy public key to nodes
ssh-copy-id -i ~/.ssh/mesh_deployment_ed25519.pub root@10.11.12.1
ssh-copy-id -i ~/.ssh/mesh_deployment_ed25519.pub root@10.11.12.2
ssh-copy-id -i ~/.ssh/mesh_deployment_ed25519.pub root@10.11.12.3

# Update Ansible inventory to use this key
# In inventory/hosts.yml:
# ansible_ssh_private_key_file: /root/.ssh/mesh_deployment_ed25519

This snippet demonstrates how to generate an ed25519 key pair (a more secure option than RSA) and copy the public key to the target nodes using ssh-copy-id. Additionally, it guides you on updating the Ansible inventory to use the newly generated key.

Option 3: Storing Keys in a Docker Volume (Ideal for CI/CD)

This option is tailored for CI/CD environments, where you might want to store SSH keys in a Docker volume for persistence.

# In docker-compose.yml, add:
volumes:
 ssh_keys:
 driver: local

services:
 ansible:
 volumes:
 - ssh_keys:/root/.ssh

By defining a Docker volume named ssh_keys and mounting it to the /root/.ssh directory within the Ansible container, you ensure that the SSH keys are preserved across container restarts. This is crucial for automated deployment pipelines.

Security Considerations: Safeguarding Your Keys

Security is paramount when dealing with SSH keys. Let's outline some key security considerations:

DO:

• ✅ Use SSH keys (never passwords in production): SSH keys provide a significantly higher level of security compared to passwords.
• ✅ Use ed25519 keys (more secure than RSA): ed25519 is a modern elliptic-curve cryptography algorithm that offers enhanced security.
• ✅ Set proper permissions (600 for private key, 644 for public key): Restricting access to the private key is essential. The 600 permission ensures that only the owner can read and write the private key, while 644 for the public key allows anyone to read it.
• ✅ Mount keys read-only in the container (:ro): Mounting the keys as read-only prevents accidental modification or deletion from within the container.
• ✅ Add SSH keys to .gitignore (already done): This prevents accidental commits of your private keys to the repository.
• ✅ Use ssh-agent for temporary key storage: ssh-agent allows you to store your private key in memory for a limited time, reducing the risk of exposure.
• ✅ Rotate keys periodically: Regularly rotating your SSH keys is a best practice for security.

DON'T:

• ❌ Commit keys to the repository: This is a major security risk.
• ❌ Share private keys: Keep your private key confidential.
• ❌ Use the same key for multiple purposes: Dedicate specific keys for different applications or environments.
• ❌ Use weak passwords on keys: If you choose to password-protect your SSH key, use a strong, unique password.
• ❌ Store keys in the image: Avoid embedding SSH keys directly into the Docker image, as this can lead to exposure.

Verification Steps: Ensuring Everything Works

To confirm that our SSH key management configuration is functioning correctly, we'll perform the following verification steps:

1. Check keys mounted correctly:

docker-compose exec ansible ls -la /root/.ssh
# Should see: id_rsa, id_rsa.pub (or id_ed25519, etc.)

This command lists the contents of the /root/.ssh directory within the Ansible container, verifying that the keys are mounted as expected.

2. Verify permissions:

docker-compose exec ansible stat -c "%a %n" /root/.ssh/id_rsa
# Should show: 600 /root/.ssh/id_rsa

This command checks the permissions of the private key (/root/.ssh/id_rsa), ensuring that it's set to 600.

3. Test SSH connection:

# To Node 1
docker-compose exec ansible ssh -o StrictHostKeyChecking=no root@10.11.12.1 echo "Success"

# If nodes not yet configured, test with:
docker-compose exec ansible ssh -o StrictHostKeyChecking=no user@example.com echo "Success"

This step attempts to establish an SSH connection to the target node (or a test server if nodes are not yet configured). The -o StrictHostKeyChecking=no option bypasses host key verification, which might be necessary during initial setup. However, it's crucial to remove this option in production and properly manage host keys.

4. Test Ansible connectivity:

docker-compose exec ansible ansible mesh_nodes -m ping -i inventory/hosts.yml

This command uses Ansible to ping the mesh_nodes group defined in the inventory/hosts.yml file, verifying that Ansible can connect to the target nodes using the configured SSH keys.

Documentation Requirements: A Clear and Concise Guide

Comprehensive documentation is essential for users to effectively set up and troubleshoot SSH key management. We'll update the docker/README.md file with the following sections:

SSH Key Setup section:

1. Prerequisites (SSH keys required)
2. Option 1: Use existing keys
3. Option 2: Generate new keys
4. Option 3: Docker volume (CI/CD)
5. Security best practices
6. Troubleshooting SSH issues

Common SSH issues:

• Permission denied → Check key permissions (must be 600)
• Host key verification → Use StrictHostKeyChecking=no or add to known_hosts
• Wrong key → Specify the correct key in the Ansible inventory
• Key not mounted → Check the docker-compose.yml volume mount

Definition of Done: Knowing When We're There

To ensure that we've successfully configured SSH key management, we'll consider the following criteria:

• [ ] SSH key setup options documented
• [ ] Keys mount correctly in the container (verified)
• [ ] Permissions are secure (600 for the private key)
• [ ] Can connect to a test host via SSH (if available)
• [ ] Troubleshooting guide complete
• [ ] Security best practices documented
• [ ] PR reviewed and merged

Alternative: Password-Based SSH (Development Only): A Word of Caution

For development and testing purposes only, password-based SSH authentication can be used. However, it's strongly discouraged for production environments.

# In inventory/hosts.yml
all:
 vars:
 ansible_user: root
 ansible_password: "your_password"  # NOT recommended
 ansible_connection: ssh

Note: Password authentication is NOT recommended for production due to its inherent security vulnerabilities.

Related Issues: Connecting the Pieces

This task is part of Milestone 1: Docker Infrastructure (Phases 1-4) and depends on #2 (docker-compose.yml). It's required for all deployment operations and blocks Phase 3 (Ansible configuration testing).

References: Diving Deeper

For further information and guidance, refer to the following resources:

• SSH key generation: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
• Ansible SSH: https://docs.ansible.com/ansible/latest/user_guide/connection_details.html
• Docker secrets: https://docs.docker.com/engine/swarm/secrets/

By following these guidelines and best practices, you can establish a secure and efficient SSH key management system for your node access, ensuring the integrity and confidentiality of your deployments. Remember, security is an ongoing process, so stay vigilant and adapt your practices as needed. Guys, let's keep those keys safe and our systems secure!