Hello.
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
but
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
AuthorizedKeysFile
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
“.ssh/authorized_keys”.
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 “id_dsa.pub” which has the public key. It should contain one very long line.
Assuming that you can login with password, then you can do
cat id_dsa.pub
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.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Code: --------------------
>
> cat id_dsa.pub
>
> --------------------
>
> 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:
ssh-copy-id youruser@remote.box.goes.here
Put in password once, then login normally:
ssh youruser@remote.box.goes.here
[youruser@] is optional both times if the local and remote usernames are
the same, of course.
Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQdJHzAAoJEF+XTK08PnB5tLAQAMdtUhEj9rDNbI2ff9fJ4iKr
AE5NMsUgx7RYNOnkX2h/v9Edi0D1YEeYEl/7yhSTMBThIDGEfxrqsv7LhwaM3DLA
jxJtRH/DNOlmP1TnicedumSE/Hse4oOxfolPKxlu6g0gpegeZiYbRernqSO36/79
X5bLcxRnmxuUTgIg/lTBSu9zQAW1wHQyWV8Tas6ihTkEwD3kmB1t82tqTYDPCBy8
d9SRtoRv9DCIb7zVo0+6LfvoDU2v1D2v1qswJ79ze2UIkcpd5BKQ/zuRqQTyCSvv
RELJfCN/6o5rJCFMK90eUQzB6pnou26x35BqIq8aBv+f87E6KmtohYYIloPJSWn8
r5ix+miNeNIrbiLG1fuH3WQHlAUD7v1tWrTKzBiywWoEowQkcIjbP8cxt3ZbjYhY
menCDmt8cHEhPUs6J8Abp6ZGYOCu+w2QQdee9wqS8kJHp9ZtgY1jAQZNwe41CaxR
Wh9Ocq6vgFy7JxSvAEO0mrqfFvEBJpnmfCpyOxuGT42o9Ib0wC3QSbISgOfI9jH+
xoMXOayFWMLHrVVT2U5pKs08jnrqw0XbRF2Z+KNBuMmvqxe2EPNt4bpzwTMXbVvC
xXqrwOfVzJuesEXm4rZEUCgfizhZoT2zZJpG8FulsHkdiKzLd3GEjbty4WZMNoMR
uYH/j6Z2MKQVJKQCbvPP
=uxvs
-----END PGP SIGNATURE-----
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”.
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iQIcBAEBAgAGBQJQdL0nAAoJEF+XTK08PnB5WFUP/im+skePAolMCwzrIbu2gqmg
yymUr65VbjRICF8cSqXqHIf68x0UOl4URSbHncCMjopu5fAAnnDaAP7sdO/z+Qq9
/iEaEdLM8DWeiLwzwXQjvKe4etdFzzep5agLw8XrbyMmeACvP0bRFucyHnCro/uK
rzyepxwza/bOhKoNSdYKIUAyNf4U/yV8sYs4cVHnX/m5wKNG6k6wgRGbGSwN6onT
Akiqv26+U96pIExWzFrMEyhDwOihcJlYfEO0eR/F7m4bNdWLgMixJk1SGMhIv5mj
JAR2WYK1ofURO/cnCtD0wvlKfiVp2ZXn9rjDLnDW8Wl4A9wmckbJ2qAsBKBbvIsn
MGXBnhHVNl86SFucHZv9/QQ0ShZB9lUXQ1wPD4RGZAh9BNvR+tWjp/Aa0+5ZKB9B
XADHUGRfuaHyh9jQn++H21BnFSpMmlc13auIBGNuVcdgw37HdVAy1bkKmEddFgZJ
UkDpTeqd+iIJQy5qcOgBRn1Crpa8s3k7fK/PnNX02UVnzxuKf/eSPGQVFKpfOrA+
VEsFnYWvhtmiuGXOo60ait790gXCyDVLzFDX7kW94AuodQB9mgnaJqXo8tGANXBj
EKOfwWzTxi12VinjbJYhFDWclGYQF9wbvv2HKHUIe01C+h2/TTYQ6lHsh3CQeyaZ
fgQxxXY3HMIv10Zk2IHc
=sfRu
-----END PGP SIGNATURE-----
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
AuthorizedKeysFile=/user-ssh-keys/%u
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.
Hello.
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.