Secure SSH Access Using 1Password SSH Agent Vault – No Local Key Storage Required!

Why Do We Need This?

In many of our teams, users, including developers, DevOps engineers, and other technical staff, require SSH access to multiple machines. Traditionally, SSH keys have been shared among users, which introduces security risks, as keys can be lost, mismanaged, or exposed. Additionally, assigning and revoking keys when team members join or leave the team is a labor-intensive task.

Possible solution we looked at

We needed a centralized and secure approach where SSH keys are stored in a vault, rather than being distributed across individual local machines. Users are granted read-only access to the vault, allowing them to authenticate without downloading or manually managing SSH keys.

Tool We found 1Password SSH Agent

After evaluating different solutions, we found 1Password SSH Agent to be the best fit. With this setup, users can log in seamlessly using:

ssh user@hostname

No need to download , specify or handle keys manually—the 1Password agent securely manages authentication in the background. Let's explore how this works on a windows machine

To use the 1Password SSH agent on Windows, you need to configure 1Password’s built-in SSH agent feature, which allows you to securely manage and use your SSH keys stored in 1Password. Here’s how to set up and use the 1Password SSH agent on Windows:

Steps to Use the 1Password SSH Agent on Windows:

1. Install and Set Up 1Password on Your System

  • If you haven’t already installed 1Password on your Windows machine, download it from the 1Password website.
  • Sign in to your 1Password account.

2. Enable SSH Agent Feature in 1Password

1Password includes an SSH agent that allows you to securely store and use SSH keys directly from your 1Password vault.

  • Open the 1Password app.
  • Go to Settings.
  • Navigate to the Developer section.
  • Toggle on the option for “Use 1Password as your SSH Agent”.

This will configure 1Password to act as an SSH agent for your system.

3. Add SSH Keys to 1Password

To use SSH keys with the 1Password agent, you’ll need to store your private SSH keys in 1Password.

  • In 1Password, click + New Item and choose SSH Key from the list of options.
  • Add your private SSH key (typically from a file like id_rsa), and you can also set a label or other metadata for the key.
  • Save the key.

This key is now stored in your 1Password vault and will be used by the 1Password SSH agent.

4. Configure SSH to Use the 1Password Agent

Next, you need to configure your SSH client to use the 1Password SSH agent. The 1Password SSH agent runs on a named pipe that acts similarly to the ssh-agent provided by OpenSSH.

  • Open your SSH configuration file:
    • Path: C:\Users\YourUsername\.ssh\config (create this file if it doesn’t exist).
  • Add the following configuration to ensure the SSH client uses the 1Password agent:
Host *
IdentityAgent \\.\pipe\openssh-ssh-agent

This configures the SSH client to use the 1Password agent for all hosts (Host * applies to all SSH connections).

5. Test SSH Authentication with 1Password

Once the 1Password SSH agent is enabled and the configuration is in place, test it by connecting to an SSH server.

For example:

ssh user@hostname

The 1Password SSH agent should now provide the stored SSH key for authentication. If you have multiple SSH keys in 1Password, the agent will offer the appropriate key for the host you’re connecting to.

6. Using 1Password CLI (Optional)

If you prefer more control or want to use 1Password’s CLI tool, you can install the 1Password command-line tool and manage SSH keys and other credentials directly from your terminal.

To install the 1Password CLI on Windows, use PowerShell:

Invoke-RestMethod -Uri https://downloads.1password.com/cli/1password-cli-win64.zip -OutFile 1password-cli-win64.zip
Expand-Archive 1password-cli-win64.zip -DestinationPath C:\op

You can then run op commands to interact with your 1Password vault. However, the built-in SSH agent in the desktop app is usually sufficient for SSH key management.

Key Features of 1Password SSH Agent:

  • Automatic Key Usage: 1Password automatically offers the correct SSH key when authenticating with an SSH server, without needing manual ssh-add commands.
  • Enhanced Security: SSH keys are stored securely in your 1Password vault, protected by your master password and 2FA.
  • Cross-platform: The 1Password SSH agent works across multiple operating systems, including Windows, macOS, and Linux.

Summary

By enabling the 1Password SSH agent and configuring SSH to use it via the IdentityAgent option, you can seamlessly authenticate SSH connections on Windows using the SSH keys securely stored in your 1Password vault. This allows you to centralize SSH key management and take advantage of 1Password’s security features.

AWS Private Link – Shared Resource for Multi VPC

Setting up a common resource across different environments is always a redundant task, It not only incurs cost , it also takes time to test and validate the same , one such use case we see with is setting up a  License server with every new environment ( prod1, prod2 etc  ) , This redundant server setup problem can be solved , if the license server can be deployed as a shared resource and consumed from different environments deployed in different VPC’s.  

There are different solutions to solve the problem,  AWS private link is one solution for the same, it helps in setting up a shared resource in one VPC and provide  access to the client / environment configured  in another VPC without compromising on security and not exposing the traffic over internet.

More Info –   AWS private Link  – https://aws.amazon.com/privatelink/

AWS private link  can be configured using the following two VPC resources.

1) Endpoint Service ( Producer side  ,  used for exposing the shared resource via a Network load balancer- NLB )
2) Endpoint (Consumer  side, used for consuming the shared resource exposed using Endpoint service via a  Elastic Network interface – ENI  )

Endpoint service and Endpoint can be configured in different VPC’s within the same region Let’s see how an Endpoint Service and an Endpoint can be configured

Endpoint service (Producer side)

1) Endpoint service configuration can be done in any shared environment which can be consumed by different clients / environments.
2) Network Load Balancer ( NLB ) is a prerequisite for creating endpoint service and need to be configured with Endpoint service.
3) NLB can configured to the target where the shared resource is deployed.
4) In the current License server setup, license server is installed on EC2 as NLB target.

Endpoint Service Creation :

1) Go to VPC console, Select Endpoint Service from the left panel
2) select Endpoint and provide the required configuration.

Endpoint  ( Consumer side  )

Endpoint configurations need to be done on the consumer side for consuming the shared resource.
Endpoint requires the name of Endpoint Service.

Elastic Network Interface ( ENI ) is created and attached to Endpoint once the endpoint is created.    
Private IP address of the ENI acts as interface for accessing the shared resource exposed through Endpoint service.                                                                                                                                                                                                                      
Endpoint Creation :

1) Go to VPC  console , Select End point from the left panel as follows   
2) Select Endpoint and provide the required configuration as follows
2.1) select other endpoint service and give the name of the service ( this is name of the endpoint service , Eg: com.amazonaws.vpce.us-east-1.vpce-svc-XXXXXX) to be consumed.
        2.2) Click submit once the endpoint service name is given ,  once done with submit an Endpoint ( Interface Type ) is created along with a  Network Interface as shown below.
        2.3) Once Endpoint is created , it will not be ready to use, it requires an additional step of  approving respective endpoint from endpoint service console. After End point is approved from End point service , the status of Endpoint is shown as Available , until then we will see the status as Pending for approval Once the end point status is Available , end point is ready to be consumed using the private IP address of the Network interface created along with the End point.

** Private  IP address  of network interface used for consuming the shared endpoint service.  

Linking  Endpoint to Endpoint service –

1) Once Endpoint Service and Endpoint is configured, next step is to link Endpoint to Endpoint service for consuming the shared resource hosted on Endpoint Service.  
2) For approving Endpoint from Endpoint service, go to  Endpoint Service -→  Endpoints tab ,  select the respective endpoint and click on action and approve the End point.
3) Once done  , endpoint is ready to be consumed using the private IP address of the elastic network interface ( ENI ).  

Accessing Shared resource  –

Once Endpoint Service  and Endpoint are configured , clients  can access the shared service hosted with Endpoint service using Elastic Network Interface ( ENI ) private IP address created with Endpoint.

Accessing Centralized License Server:

our App makes use of Docker plugin for accessing the Licensed server.

docker plugin discovers the Licensed server using predefined IP , therefore following additional steps are required for accessing the centralized license server.

Launch a t3.nano machine  which acts as a proxy machine to connect to Endpoint.
Have a predefined IP – xxxx for the proxy machine  , This is a predefined IP configured for plugin for discovering the licensed server.  

To access the centralized license server from  the proxy machine,  Tunnel is configured  between Proxy machine and ENI  as follows

The Linux utility simpleproxy can be used to setup the proxy, once the utility is installed you can use the following command to setup the proxy.  

Eg : simpleproxy -L portno -R x.x.x.x:portno

x.x.x.x is  the IP address of the Network interface which will be pointing to the centralized server configured using AWS private link.

portno is port on which license server is listening for the incoming license requests.

Tunnel is setup as a service on the proxy machine using the following steps to make sure it’s up and running even after system restarts.

install simpleproxy  utility , more info on the untility  :  https://manpages.ubuntu.com/manpages/kinetic/en/man1/simpleproxy.1.html

usage of simpleproxy command

simpleproxy -L [local port on which you want to listen for remote requests] -R [remote host:remote port for which you want to proxy/tunnel to]

once simple proxy is installed , create a file named simpleproxy.sh  in /tmp  and add the following content.

simpleproxy -L 22350 -R 10.0.26.109:22350

Go to the directory :   cd /etc/systemd/system
Create a file named xxx-service.service and include the following

[Unit]
Description=xxx service

[Service]
User=root
WorkingDirectory=/tmp
ExecStart=/tmp/simpleproxy.sh
Restart=always

[Install]
WantedBy=multi-user.target
save the above file and then start the service using the following command.
systemctl start xxx-service.service

Once complete above configuration is in place ,  we are good to validate the centralized license server.