| Title: Improve your SSH agent security | |
| Author: Solène | |
| Date: 24 May 2024 | |
| Tags: ssh openbsd security | |
| Description: In this article, you will learn a few tips to enhance the | |
| security of the software holding your SSH keys | |
| # Introduction | |
| If you are using SSH quite often, it is likely you use an SSH agent | |
| which stores your private key in memory so you do not have to type your | |
| password every time. | |
| This method is convenient, but it comes at the expense of your SSH key | |
| use security, anyone able to use your session while the agent holds the | |
| key unlocked can use your SSH key. This scenario is most likely to | |
| happen when using a compromised build script. | |
| However, it is possible to harden this process at a small expense of | |
| convenience, make your SSH agent ask for confirmation every time the | |
| key has to be used. | |
| # Setup | |
| The tooling provided with OpenSSH comes with a simple SSH agent named | |
| `ssh-agent`. On OpenBSD, the agent is automatically started and ask to | |
| unlock your key upon graphical login if it finds a SSH key in the | |
| default path (like `~/.ssh/id_rsa`). | |
| Usually, the method to run the ssh-agent is the following. In a shell | |
| script defining your environment at an early stage, either your | |
| interactive shell configuration file or the script running your X | |
| session, you use `eval $(ssh-agent -s)`. This command runs ssh-agent | |
| and also enable the environment variables to make it work. | |
| Once your ssh-agent is correctly configured, it is required to add a | |
| key into it, now, here are two methods to proceed. | |
| ## OpenSSH ssh-add | |
| In addition to ssh-agent, OpenSSH provides ssh-add to load keys into | |
| the agent. It is simple of use, just run `ssh-add /path/to/key`. | |
| ssh-add manual page | |
| If you want to have a GUI confirmation upon each SSH key use, just add | |
| the flag `-c` to this command line: `ssh-add -c /path/to/key`. | |
| In OpenBSD, if you have your key at a standard location, you can modify | |
| the script `/etc/X11/xenodm/Xsession` to change the first occurrence of | |
| `ssh-add` by `ssh-add -c`. You will still be greeting for your key | |
| password upon login, but you will be asked for each of its use. | |
| ## KeepassXC | |
| It turns out the password manager KeepassXC can hold SSH keys, it works | |
| great for having used for a while. KeepassXC can either store the | |
| private key within its database or load a private key from the | |
| filesystem using a path and unlock it using a stored password, the | |
| choice is up to you. | |
| You need to have the ssh-agent variables in your environment to have | |
| the feature work, as KeepassXC will replace ssh-add only, not the | |
| agent. | |
| KeepassXC documentation has a "SSH Agent integration" section | |
| explaining how it works and how to configure it. | |
| KeepassXC official documentation | |
| In the key settings and "SSH Agent" tab, there is a checkbox to ask | |
| user confirmation upon each key use. | |
| # Other security features | |
| ## Timeout | |
| I would recommend to automatically delete the key from the agent after | |
| some time, this is especially useful if you do not actively use your | |
| SSH key. | |
| In `ssh-add`, this can be achieved using `-t time` flag (it's tea time, | |
| if you want to remember about it), where time is a number of seconds or | |
| a time format specified in sshd_config, like 5s for 5 seconds, 10m for | |
| 10 minutes, 16h for 16 hours or 2d for 2 days. | |
| In KeepassXC, it's in the key settings, within the SSH agent tab, you | |
| can configure the delay before the key is removed from the agent. | |
| # Conclusion | |
| The ssh-agent is a practical software that ease the use of SSH keys | |
| without much compromise with regards to security, but some extra | |
| security could be useful in certain scenarios, especially for | |
| developers running untrusted code as their user holding the SSH key. | |
| While the extra confirmation could still be manipulated by a rogue | |
| script, it would come with a greater complexity at the cost of being | |
| spotted more easily. If you really want to protect your SSH keys, you | |
| should use them from a hardware token requiring a physical action to | |
| unlock it. While I find those tokens not practical and expensive, they | |
| have their use and they can not be beaten by a pure software solution. |