Key and Agent Problems (Unix Power Tools, 3rd Edition)

51.6. Key and Agent Problems

Q: I generated a key with SSH1 and tried using it with another SSH1 client, such as NiftyTelnet SSH, F-Secure SSH Client, or SecureCRT, but the client complains that the key is in an invalid format.

A: First, make sure you generated the key using ssh-keygen1, not ssh-keygen2. SSH1 and SSH2 keys aren't compatible.

Next, make sure you transferred the key file using an appropriate file-transfer program. If you used FTP, confirm that the private key file was transferred in binary mode, or the copy will contain garbage. The public key file should be transferred in ASCII mode.

Q: I generated an SSH1 key and tried using it with SSH2, but it didn't work. (Or vice versa.)

A: This is normal. SSH1 and SSH2 keys aren't compatible.

Q: I specified a key manually, using -i or IdentityFile, but it never gets used!

A: Are you running an agent? If so, -i and IdentityFile don't have any effect. The first applicable key in the agent takes precedence.

Q: Each time I run ssh-keygen, it overwrites my default identity file.

A: Tell ssh-keygen to write its output to a different file. For ssh-keygen in SSH1 and OpenSSH, use the -f option. For ssh-keygen2, specify the filename as the last argument on the command line; no option is needed.

Q: Can I change the passphrase for a key without regenerating the key?

A: Yes. For ssh-keygen in SSH1 and OpenSSH, use the -N option, and for ssh-keygen2, use the -p option.

Q: How do I generate a host key?

A: Generate a key with an empty passphrase and install it in the correct location:

# SSH1, OpenSSH
$ ssh-keygen -N '' -b 1024 -f /etc/ssh_host_key
# SSH2 only
$ ssh-keygen2 -P -b 1024 /etc/ssh2/hostkey

Q: Generating a key takes a long time.

A: Yes it may, depending on the speed of your CPU and the number of bits you have requested. DSA keys tend to take longer than RSA keys.

Q: How many bits should I make my keys?

A: We recommend at least 1024 bits for strong security.

Q: What does oOo.oOo.oOo.oOo mean, as printed by ssh-keygen2?

A: The manpage calls it a "progress indicator." We think it's an ASCII representation of a sine wave. Or the sound of a chattering gorilla. You can hide it with the -q flag.

Q: My ssh-agent isn't terminating after I log out.

A: If you use the single-shell method to start an agent, this isnormal. You must terminate the agent yourself, either manually (bleah)or by including appropriate lines in your shell configuration files (Section 5.3). If you use the subshell method, the agent automatically terminates when you log out(actually, when you exit the subshell) (Section 6.3).

Q: When I invoke ssh-add and type my passphrase, I get the error message "Could not open a connection to your authentication agent."

A: Follow this debugging process.

Make sure you are running an ssh-agent process:

$ /usr/bin/ps -ef | grep ssh-agent
smith 22719     1  0 23:34:44 ?        0:00 ssh-agent

If not, you need to run an agent before ssh-add will work.

Check that the agent's environment variables are set:

$ env | grep SSH
SSH_AUTH_SOCK=/tmp/ssh-barrett/ssh-22719-agent
SSH_AGENT_PID=22720

If not, you probably ran ssh-agent incorrectly, like this:

# Wrong!
$ ssh-agent

For the single-shell method, you must use eval with backquotes:

$ eval `ssh-agent`

Or, for the subshell method, you must instruct ssh-agent to invoke a shell:

$ ssh-agent $SHELL

Make sure the agent points to a valid socket:

$ ls -lF $SSH_AUTH_SOCK
prwx-- -- --   1 smith   0 May 14 23:37 /tmp/ssh-smith/ssh-22719-agent|

If not, your SSH_AUTH_SOCK variable might be pointing to an old socket from a previous invocation of ssh-agent, due to user error. Terminate and restart the agent properly.

Q: My per-account server configuration isn't taking effect.

A: You might be confused about which versions of SSH use which files:

SSH1, OpenSSH/1: ~/.ssh/authorized_keys

SSH2: ~/.ssh2/authorization

OpenSSH/2: ~/.ssh/authorized_keys2 (note this isn't in ~/.ssh2)

Remember that the authorized_keys and authorized_keys2 files contains keys, whereas the SSH2 authorization file contains directives referring to other key files.

You might have a typographical error in one of these files. Check the spelling of options, and remember to separate SSH1 authorized_keys options with commas, not whitespace. For example:

# correct
no-x11-forwarding,no-pty 1024 35 8697511247987525784866526224505...
# INCORRECT (will silently fail)
no-x11-forwarding no-pty 1024 35 8697511247987525784866526224505...
# ALSO INCORRECT (note the extra space after "no-x11-forwarding,")
no-x11-forwarding, no-pty 1024 35 8697511247987525784866526224505...

-- SP