OSX ssh-agent: no password pasting, and problem with PKCS#8?

Question

I use ssh on my machine, and have set up a long not-human-friendly passphrase which is saved in my password manager. What makes me crazy every time is that I cannot paste into the window pictured below. I know the Remember password in my keychain option and use it. Sometimes I have to enter a new one though. Why can't I paste into a password field?

Same thing for the dialog which pops up when plugging in encrypted disks.

Some updates:

1. I found out how i can circumvent the dialog: just use ssh-add -K ~/.ssh/id_rsa, and then I can paste the passphrase into the terminal.
2. As mattmcmanus mentioned, my Key is encryted using pkcs8 which was broken on Yosemite's ssh-agent. This is unrelated to the above problem, but it did occur to me at the same time (read here).
3. using ssh-add still not fixes this for encrypted disks.

Answer 1

1. The dialog for ssh-agent can be circumvented by adding the key in the console/terminal: ssh-add ~/.ssh/id_rsa. You can then paste the password into the terminal. Also, adding the -K option to ssh-add will save it to the keychain as per Oliver Lacans comment.
2. As mattmcmanus said, id_rsa encryption using PKCS seems to be broken on OSX Mavericks ssh-agent. The fast workaround is to decrypt the keyfile, and encrypt it again with the standard ssh procedure (Key-derivation method: MD5...):

---

mv id_rsa id_rsa.pkcs
openssl rsa -in id_rsa.pkcs -out id_rsa
# enter passphrase to decrypt
chmod 0600 id_rsa
ssh-keygen -f id_rsa -p
# enter passphrase to encrypt again

Answer 2

Is it a PKCS#8 key and are you on mavericks? If so, that seems to be completely busted. Not sure there is a solution yet.

Answer 3

On Mac OS X El Capitan the ssh-add command can do this with a -K option:

$ ssh-add -K ~/.ssh/id_rsa
Enter passphrase for /Users/your.username/.ssh/id_rsa:

You can paste your password into this prompt with ⌘-V.

A session for this looks like this:

$ ssh-add -K ~/.ssh/id_rsa
Enter passphrase for /Users/your.username/.ssh/id_rsa:
Passphrase stored in keychain: /Users/your.username/.ssh/id_rsa
Identity added: /Users/your.username/.ssh/id_rsa (/Users/your.username/.ssh/id_rsa)

Relevant excerpt of SSH-ADD(1) brought up with man ssh-add:

-K When adding identities, each passphrase will also be stored in your keychain. When removing identities with -d, each passphrase will be removed from your keychain.

INFOSEC NOTE: Your password won't be shown in the shell, but will be exposed to all running applications via the clipboard. An autotype solution would be more secure.

Answer 4

You can run a script like this in AppleScript Editor:

tell application "System Events" to tell process "SecurityAgent"
    set value of text field 2 of scroll area 1 of group 1 of window 1 to "pa55word"
    click button 2 of group 2 of window 1
end tell

Answer 5

I had the same problem. After finding this question, I kept looking and found an answer elsewhere. This is an older question, but it has no accepted answers and is still high on search lists. (not sure of the stackexchange etiquette on that).

RE not being able to copy/paste: It's apparently by design. The intention is to prevent all access to the field from the clipboard to prevent a malicious program from scraping password boxes. I'd think pasting (and not cutting) should be allowed, but maybe there's some technical reason.

For the ssh-agent stuff, as of (at least) Yosemite, the -K option in ssh-add -K ~/.ssh/blah does what you'd like -- type the password once, it's stored in your keychain, and ssh-agent will transparently unlock for you. To try and be safer, I put my ssh passphrases in a separate keychain that locks itself periodically.

Answer 6

Using brew openssl and openssh fixes the issue.

brew update
brew install openssl
brew link openssl --force
brew install openssh

# confirm correct bins are being used
# both should be located in /usr/local/bin
which openssl
which openssh

# add key back to keychain
ssh-add ~/.ssh/id_rsa

I'm not sure if force linking openssl breaks anything on Mavricks. So far, I haven't noticed any issues.