SSH - sshd_config - HostKey parameter

Is it possible to use %u in the HostKey parameter.

HostKey /etc/ssh/private_pub_key/%u/id_dsa ==> unable to start sshd

TIME Oct 7 21:58:49,PR 6,FCLTY 3,HOST linux-srv, §§TAG§§ sshd[15415]:, §§MSG§§ Could not load host key: /etc/ssh/private_pub_key/%u/id_dsa


HostKey /etc/ssh/private_pub_key/root/id_dsa ==> OK

The hostkey is specific to the host. If “%u” is supposed to refer to a user, then that won’t work. The host key is a fixed key seen by any connection to the server, even before a username is known.

It is best to stick to the defaults, and not redefine the hostkey unless you are really experience with ssh.

It looks to me as if you are trying to setup publickey authentication. But that is entirely different from host-based authentication.

Perhaps you need to describe, in more detail, what you are really trying to achieve.

I have just misunderstood that.

I am just using publickey authentication.

Thank you for helping.

Thread is closed

Sorry to come back but any idea for this part of the man page

Specifies the file that contains the public keys that can be used for user authentication. The format is described in the
AUTHORIZED_KEYS FILE FORMAT section of sshd(8). AuthorizedKeysFile may contain tokens of the form %T which are substituted
during connection setup. The following tokens are defined: %% is replaced by a literal ‘%’, %h is replaced by the home
directory of the user being authenticated, and %u is replaced by the username of that user. After expansion,
AuthorizedKeysFile is taken to be an absolute path or one relative to the user’s home directory. The default is

Normally, you place the public key (not the private key) in $HOME/.ssh/authorized_keys on the system where you want to login. You keep the private key in your “.ssh” directory in the client system from which you are connecting.

Based on your first post, I’m assuming that you have a key in file “id_dsa”. In that case, there should also be a file named “” which has the public key. It should contain one very long line.

Assuming that you can login with password, then you can do


and copy that line with your mouse. Then login to the remote system, edit the file “.ssh/authorized_keys”, and paste the public key into the file as the last line.

After that, you should be able to login with public key authentication.

My preferred method is to use “ssh_agent” which seems to be automatically started when I login to KDE or other desktop. Then I can use

ssh-add id_dsa

and give my pass phrase once. Then that works for login without password for the rest of my desktop session.

I hope that helps. I guess I’m not sure what you are asking.

If you really want to change the AuthorizedKeysFile from the default, you can do that. But it is typically easier to just go with the default. It is set on the server system that to which you are connecting.

Hash: SHA1

> Code: --------------------
> cat
> --------------------
> and copy that line with your mouse. Then login to the remote
> system, edit the file “.ssh/authorized_keys”, and paste the public
> key into the file as the last line.

Yes, but please use ssh-copy-id in the future as follows:


Put in password once, then login normally:


[youruser@] is optional both times if the local and remote usernames are
the same, of course.

Good luck.
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


Thanks. I didn’t know about that one. I set up my keys a zillion years ago. If I need them on a new system, I just use “scp”.

Hash: SHA1

This command is better for a couple reasons. First, it appends to the
file (so you don’t overwrite it each time, or need to scp, and then
after that use ‘ssh’ to append).

Second, it verifies permissions. Most people who use keys have probably
hit the situation where either authorized_keys or its containing
directory structure has permissions allowing other users to change
things which ‘sshd’ recognizes and then prevents login (or can at
least). ssh-copy-id fixes permissions to prevent that situation which
is really frustrating the first time you hit it.

Good luck.
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


This is not my question.
I can configure Openssh the standard way for long times.
I stumbled upon several documents (including one by ORACLE Corp. and on UBUNTU site) that indicate the possibility to parametrize sshd_config using tokens such as% u.
After the first remark from nrickert I read the manpage and it seems to confirm the possibility to parametrize AuthorizedKeysFile with% u.
As indeed it is not working from my test, I wonder if there is a bug in the manpage or if there is something else that escapes me.

So what ?

I’ve just reread that man page (for sshd_config). Here is how I am reading it.

If the AuthorizedKeysFile is a relative path (the first character is not “/”), then it is already relative to the home directory of the user. It is not clear to me why anyone would use “%u” in that case.

Instead, the AuthorizedKeysFile could specify an absolute path. For example, an administrator might set a security policy requiring that user public keys be approved by management. So he might define the path with, say


so that all approved keys are in a central location. Presumably the file, in that case, would be owned by root.

I have not tested whether this works, as I never had the inclination to be a paranoid control freak.


Restarting from the beginning, it’s working.
I guess I had a missconfigured ownership and/or mode 600 for one of the config files.

In ssh_config :

IdentityFile            /etc/ssh/id_keys/%u/id_rsa

In sshd_config :

AuthorizedKeysFile                /etc/ssh/server/%u/authorized_keys

Thread is closed.

Thank you for your patience.

Thanks for that final post, where you said what worked for you. That can help other users with similar problems.