[Mageia-discuss] password-less ssh

[Maarten Vanraes]

Op zaterdag 24 september 2011 20:34:49 schreef Juergen Harms:
> 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.


maybe it's a security feature, if it's a symlink it might point to somewhere 
where other users have access to? or something? i'm just plain wildly guessing 
here.

Perhaps you can find the upstream changelog between those 2 versions and see if 
this is documented somewhere.

on top of that, you can ask the upstream if it's wanted to not allow symlinks 
for authorizedkeyfiles...