I use tmux quite heavily on my server now. I like it so much, in fact, that I have my shell configured to connect to (or start) a session as soon as I log in. So, however I log in (at the console, in a terminal emulator, via SSH), I always get the same view of my command lines. However, one issue that’s been bugging me for a year is a problem with entering SSH passphrases to the SSH agent.
Background
When connecting to an SSH server, there are two main ways of authenticating yourself. The simplest (because it just works out of the box) is “keyboard-interactive” whereby the SSH client stops during the login phase and asks you for a password. This is then securely transmitted to the host and used in the same manner as logging in at a console (that is, passed to PAM). Now, this does work nicely, but if you’re logging into a machine regularly, or logging into many machines, or want something more secure, then there’s a better method.
Public Key authentication uses the same Public/Private Key cryptography that’s become popular all across the web. You generate a pair of keys – one private that you keep safe (in SSH’s case, you keep it on the client) and one public that you distribute widely (in SSH’s case, you copy it to the server that you want to connect to). By matching the keys, both ends of the connection can authenticate each other.
There are plenty of good guides around for setting up Public Key authentication, and I don’t intend this post to repeat them but, in summary, one generates the keypair on the client using ssh-keygen and appends the public part of the key (typically in ~/.ssh/id_*.pub) to the host’s “authorized_keys” file (~/.ssh/authorized_keys). Now, when you connect to the host, the key is used instead of a password.
Agents
Now, the use of keys can be simplified by the application of an SSH Agent. An SSH Agent is any program that will load the keys into memory and provide them to an SSH client. The benefit is that, if you password-protect the keys (which could be a different password to the password for user@server), you only need to enter the password once (to the agent), or rarely (if the agent is set to periodically forget the password for security).
And this is where the problem I was having came. TMUX was launching an SSH Agent at startup and, when I started new windows, these were told to re-use the existing agent. This is right and good and how you’re supposed to do things – One SSH Agent process, to which all your shells connect. However, when the agent needed to ask for a password, the prompt would only appear in that first pane. If I wasn’t actually connecting in the first pane, then entering characters would become an odd race – some keys would go to the password field and some would go to the application that was running in pane 1. And sometimes – say if I’d closed pane 1 – then the pinentry process would spin, using 100% CPU.
The Problem
So, it turned out that all this bother was caused by using the wrong SSH agent.
GPG, which also can use an agent for passphrase caching, has a mode where it can also cache SSH keys, which I was using. However, it turns out that this is quite buggy. I found that if I removed the enable-ssh-support directive from ~/.gnupg/gpg-agent.conf, then OpenSSH’s SSH-Agent would cache the keys instead and that behaved a lot better with tmux.
