OpenSSHWhatKeysForKeysigning

By admin

One
CARDINAL

of the authentication options of OpenSSH, if it’s enabled on both the server and the client, is host based authentication using the client’s SSH host keys. On the client, this is controlled by EnableSSHKeysign and

HostbasedAuthentication
PRODUCT

; on the server, by

HostbasedAuthentication
PRODUCT

and perhaps

IgnoreRhosts
PRODUCT

. Suppose, not hypothetically, that you use this along with some personal

SSH
ORG

keys, and

some day
DATE

you try to connect to some new system and get rudely disconnected before you get prompted for a password. The direct answer to what’s happening is that you’ve run into the server’s limit on how many different authentication options it will let you try (this can also come up if you have a lot of personal keys), set by the server’s MaxAuthTries . Further, when you run ‘ssh -v’ to see where all the identities are coming from, a number of them are client SSH host keys, including a type of host key that you don’t even use (you’ve explicitly set

HostKey
ORG

in your sshd_config to not include them).

Since you’re running into limits on the number of identities you can offer, and some of them are from the host keys, it would be nice to control what client host keys you offer to the server. Or at least to understand where this is set and why, for example, ‘ssh -v’ says that you’re offering a ‘ecdsa-sha2-nistp256’ host key when you don’t even use ECDSA. Unfortunately,

today
DATE

all of this is underdocumented and it’s somewhat hard to control, although not impossible.

Based on reading the source code, the decisions about what host keys to try to sign and where to find them are split between ssh-keysign and ssh itself, although in a confusing way. Both ssh and ssh-keysign look for the default, traditional names of the host keys (such as /etc/ssh/ssh_host_rsa_key) and determine what host keys to offer based on a combination of what files are present and what host key algorithms ssh likes. Ssh-keysign is ultimately responsible for reading the keys, so what it looks for and finds limits what ssh can ask for.

(Both ssh and ssh-keysign hard code these key paths, although the ssh-keysign source code has a comment that it should use your sshd_config to determine the key paths.)

There are

two
CARDINAL

ways to control what host keys are ultimately used, the brute force way and the nominally correct way. The brute force way is to entirely remove (or rename) the host key files in /etc/ssh for the host key types you don’t use. For example, if you don’t use ECDSA keys and set

HostKey
ORG

in your sshd_config to exclude them, remove /etc/ssh/ssh_host_ecdsa_key* (which was probably created automatically by, for example,

the Ubuntu Linux
PRODUCT

installer).

The nominally correct way is to change what hostbased authentication algorithms ssh will try to use (well, ask ssh-keysign to use), which is controlled by the

HostbasedAcceptedAlgorithms
ORG

directive from ssh_config (in older OpenSSH versions, this is called HostbasedKeyTypes instead). You can set this to a restricted list, or you can use the OpenSSH ‘-‘ syntax to remove some algorithms, for example:

HostbasedAcceptedAlgorithms

-ecdsa-sha2-nistp256
PERSON

The host keys that your ssh will offer to the server for hostbased authentication are those keys that are both available under their standard names in /etc/ssh and allowed by

HostbasedAcceptedAlgorithms
ORG

. Note that some key types can be used by

more than one
CARDINAL

algorithm; working out what algorithms you need to disallow is left as an exercise.

(As you’d expect, this doesn’t affect what key algorithms can be used for personal keys. If you want to use personal

ECDSA keypairs
PERSON

, you still can.)