Firstly, let me say I am aware there are many similar questions on here and other websites. I am convinced I have exhausted them, but I'd be happy to be proved wrong as I need this solved.

I have a CentOS server which has ssh access via public key for the root user. I have created a separate user (let's call it remote_user) with restricted access. As part of doing this, I have set a home directory in a different location on the machine.

As remote_user I cd'd to ~/ and created .ssh/ and .ssh/authorized_keys. I added the public key to authorized_keys (this same public key exists in root's authorized_keys, which works). I ensured that ~/ and ~/.ssh have permissions set to 700 and that ~/.ssh/authorized_keys has permissions set to 600. I ensured that all of these files are owned by remote_user.

In regards to SELinux I have tried: Turning it to permissive (temporarily), restorecon -R -v ~/.ssh/authorized_keys and using ls -Z and chcon to ensure that the remote_user/.ssh and remote_user/.ssh/authorized_keys files have the same security contexts as their corresponding root files.

The contents of /etc/ssh/ssh_config is:

Host *
    GSSAPIAuthentication yes
    ForwardX11Trusted yes

And yet no dice. Using putty, connecting to the server and entering the username root, my Paegant key grants access. When entering the username as remote_user, I am immediately prompted for my password. When I use the password, I can access it no trouble. I have also tried ssh forwarding from another server with ssh server, same result.

So what am I missing?

  • What logs can you see in the server log?
    – Jakuje
    Commented May 16, 2017 at 9:01
  • 1
    I assume the created .shh/ in your question was a question-only typo, since you then mention the correct path .ssh/authorized_keys ?
    – Jeff Schaller
    Commented Dec 5, 2018 at 13:23
  • @JeffSchaller correct. I've amended it.
    – Stringers
    Commented Dec 5, 2018 at 23:51

1 Answer 1


This all seems to be pretty much like it should be,... the only thing you don't mention is, if the machine you're trying to connect from has the private key? Perhaps it's not saved where it needs to be (~/.ssh/id_rsa for instance) - if it is not, then you have to use the following command to connect:

ssh -i <path to identity file> <username>@<hostname>

Also, I recommend that you do not copy over the identities "by hand" unless you really need to and know what you're doing, but simply use the ssh commands that facilitate this for you:

ssh-copy-id <username>@<hostname>

And that's it. That will first create a new identity file and then copy it to the host. If you already have the identity file somewhere, you can of course also use the -i <path to identity file> flag with ssh-copy-id.

EDIT: I just noticed that you mentioned you were connecting with Putty - that is a little different, and putty has it's own mechanism for this, PuTTY Key Generator.

Generate and save the private and public keys - private being the id_rsa from our earlier example that stays on the client machine, public being id_rsa.pub that needs to be copied into ~/.ssh/authorized_keys on the server machine.

Once you've done that, you need to add the private key under the Connection/SSH/Auth tab for the session you're using.

  • I've marked this correct as your answer contained the tip I needed. "Also, I recommend that you do not copy over the identities "by hand" unless you really need to and know what you're doing, but simply use the ssh commands that facilitate this for you". I had in fact done this by hand and left a character off.
    – Stringers
    Commented May 16, 2017 at 23:14
  • As a quick followup, will ssh-copy-id add the public key to my remote_users manually set remote directory even when it's different to the default ~/.ssh/ directory?
    – Stringers
    Commented May 16, 2017 at 23:15
  • No, unfortunately ssh-copy-id will always create ~/.ssh/authorized keys and make sure that the permissions are set correctly on that file. There are no flags to change this. You can still use this mechanism and then simply concatenate the ~/.ssh/authorized_keys file to whatever file you've configured sshd to look in. Commented May 17, 2017 at 6:04
  • Thanks for your answer. I think what your describing is actually the behaviour I desire and I have just explained myself badly. Thanks for the response.
    – Stringers
    Commented May 17, 2017 at 12:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .