On 09/24/2011 06:30 PM, Deri James wrote:
It "StrictModes" is turned on in sshd_conf I assume the permissions of the
link itself is checked
StrictMode no or yes does not make any difference: password still
required if login from the laptop to the server
> Another possibility is to set AuthorizedKeysFile to
> point to your file in /etc
I did not try to put my user data to /etc ..., /etc is not a place for
user-specific data, and is specific to each OS partition. I tried (and
/common is not on my root file-system - the problem might be there)
AuthorizedKeysFile /common/share/home/harms/.ssh/authorized_keys
Result: password is still required; but there is an effect: a plain
/home/harms/.ssh/authorized_keys is not seen any more.
Summary
- ssh does not correctly use an authorized_keys file if the target is a
symbolic link form $HOME/.ssh
- this problem only exists for sessions started from a laptop on a
desktop server, the other way round there is no problem
- this problem has only recently appeared
- using mount --bind for mounting $HOME/.ssh at on a template
directory results in correct behaviour
- twiddling /etc/ssh/sshd_conf (StrictMode, AuthorizedKeysFile) does
not produce satisfactory results.
For me, there is a simple workaround which I now use: rather than
creating a link to my template file, I put a copy of the template data
into $HOME/.ssh/authorized_keys (extremely unfrequent modifications, no
problem to create a new copy in case the template data really change)
The reason why I started this discussion is that there may be a faint
risk that an abnormal behaviour of ssh could create problems in
situations less obvious than a plain remote shell session - many
distributed applications use ssh "hidden" in the application.
But since I am the only one to observe this problem, opening a bug is in
my opinion not justified.
