public key auth in ssh: username check against authorized_keys

[ufalke]

Hi, the code (starting at https://github.com/dCache/dcache/blob/8e450b55061b99f0d9f08dc50da6c6f256bd22d6/modules/dcache/src/main/java/org/dcache/services/ssh2/Ssh2Admin.java#L338) checks the identity string included in the public RSA key contained in authorized_keys2. Contrary to the behaviour of openssh (and all other ssh tools I am aware of), dcache expects it to indicate the identity which should be gained, not the identity from which the login request comes. Example: I generate a key as user A on a machine M. The public key contains the identity A@M. I can use that key with all known ssh implementations by copying it to the authorized_keys of arbitrary users and login as those users -- except for dcache. For dcache, in order to log in/connect as admin, I need to substitute the string A@M by admin@x in the authorized_keys2 file. However, that is a redundant information as this file is assigned to admin anyway. Moreover, the substring after @ is not regarded at all, i.e. x can be arbitrary. Why is that check done that way? Could it be reverted to the usual ssh behaviour? It does not offer more security: whoever is able to place the key into the authorized_keys2 is also able to amend its content. Could the check be left out, or just be reduced to a formal format check?

Regards Uwe (complete newbie)

[paulmillar]

Hi Uwe,

Thanks for you interest!

Things in dCache are, perhaps, a little different from how you're imagining them. The (dCache) ssh interface is for dCache administrators. Logging into the ssh interface provides admins with an environment in which they can query the current status and modify the running dCache cluster, without requiring that any of the services are restarted. This is somewhat different from the job of a normal ssh server.

dCache admin accounts are distinct from the accounts on the host computer. Therefore, admins don't have a home directory, so no .ssh directory and no authorized_keys file. Therefore, we need another way to bind the ssh public key to the specific admin account that the user is allowed to use.

After some internal discussion, we decide to use the comment field of the ssh public key to record this information, in the form username@host. This is because ssh-keygen adds this information by default and (usually) dCache admin accounts have the same name as that person's account name on their desktop machine. You're correct: the host is ignored. This is because the information is redundant because the file is installed on the node hosting the ssh interface.

I hope that helps explain why dCache has this rather usual requirement on the list of ssh public keys.

Cheers, Paul.

[ufalke]

Hi, Paul, sure, the ssh protocol can serve many purposes. I assumed -- since The Book suggested to use the login name 'admin' for the superuser -- that establishes the search path for the authorized_keys2 file. Apparently that is not the case? Then, the directory /etc/dcache/admin/ is a generic one for all potential superuser or administrator accounts? So, regardless what ssh login attempt is performed it is always checked against the data in /etc/dcache/admin/ ? If you confirm that I will submit another patch for the documentation to avoid further confusion (simply use another name for the admin account in your first-time install guide ...). Thanks Uwe

[paulmillar]

The login name admin as an admin account is meant as an example only; for example, when I log in, I use the admin account paul.

The path /etc/dcache/admin contains all configuration about the ssh login system in general (which is sometimes called the "admin interface"). The choice admin shouldn't be confused with those files being tied exclusively to an admin account called admin.

So, yes, all login attempts for admin users (whatever the login name) makes use of files located in the /etc/dcache/admin directory.

Please feel free to submit patches to update our documentation -- we're often blinded by familiarity, so a fresh pair of eyes is always appreciated.

It also might be worth changing the name of the dcache user admin to some other name; perhaps power-user?