Most likely it’s a problem with your authorized_keys permissions and as such you should try using ssh-copy-id from the source user/machine to the target user/machine as it will set the permissions accordingly and alert you to any issues along the way.
You can run it from your client, logged in as the user whose ssh public key you wish to copy to the target server: ssh-copy-id user@targethost
Hi folks!
Thanks a lot for your suggestions, but doesn’t solve the problem. I repeat: “Tried the keys with another user and it worked”. That excludes any problems with permissions or ownerships. If I got the key running for user1 why not for user2? The key wasn’t generated on the server, so the adaption of the permissions / ownerships had to be done for user1 and user2 in the same way. The hint with the home directory was an idea, but as all users have the same permissions here, this isn’t a clue either. (Anyway I tried - but to no avail). Anyhow I assume from your answers that there isn’t any user configuration known, which could prevent the correct authorization?
The second sentence was what was causing me trouble. In my case, user1 was my main user account and user2 was a “transfer” account where I could transfer files in and out of it through my phone. (I didn’t want to give my phone access to my home directory for obvious security reasons.)
where group foo was specifically set up for making transfers. User1 was a member of that group and had writeable access. Once I changed the directory to drwxr-x— everything worked fine.
Anyway, I didn’t know this about SSH. I knew the other stuff above, but this had me stumped for a while.
One other suggestion on how to debug this is to turn on the ssh debug output (ssh -vvv) and compare/diff the output for the two users.
If you do not see what is wrong, post the output for the failing user here…