Hello,

i want to access server via SSH without need to enter password, so i thought i will generate public key and share it with server from which i will be accessing, but it do not works. Says: "# ssh -l root localhost -p 7000
Permission denied (publickey)."

why i am connecting localhost? because i set port forwarding from localhost to destination LAN/firewalled by executing command ssh -fN -R 7000:localhost:22 username@PublicServerIPhere on the server i want to connect. It should work, password access worked, but not public key, returns "Permission denied (publickey)."

Error appears even after i logged in server i want to connect and executed ssh-keygen and then ssh-copy-id IPOfTheServerFromWhichINeedPasswordLesAccess
it worked and when i re-run, it says: "All keys were skipped because they already exist on the remote system."
So key should be coppied.

Where is the problem please? This is sshd_config of the server i am trying to connect (one that refuse ssh pub. key connection and allows password connection):

source server (from which i am connecting) is CentOS(redhat), destination server which refusing pub.key access is Debian.

Thank you for help :-/

Allowing root login is a security hazard.

The configuration PermitRootLogin without-password means that you can connect root if you have keys set up, password authenticatin is blocked. You also need a public - private key pair for the root account and then place the public key on the remote server in the root account.

As smallpond points out, allowing root login is a hazard, even if using keys mitigates that some. Which problem are you trying to solve?

From Your kind reply, i am unsure what exactly i should do. From what you said i think i already did what you said but it returns mentioned error.

On the client system, as root, you'll need to create a key pair for root to use.

Then you'll need to connect to the remote machine as a regular user and use "sudo" or "su" to add the public key to the file /root/.ssh/authorized_keys. For example,

That's because you need two key pairs. One to create the tunnel, the other to connect to root. It seems you have the first key pair, if you can log in already as a normal user using the key.

What do the following do for you?

@Turbocapitalist

Thank you for help. Indeed it seems that i have to share the key both ways in this case, not only from server to the client but vice versa too (clients key to the server).

i had to set:
then service ssh reload

then i was able to push the key to the server from client by command: ssh-copy-id "127.0.0.1 -p 7000"
entering password

then change back sshd_config to:
service ssh reload

then after such change no one is prompted for password and only keys in server's authorized_keys file are allowed.

That is what i wanted. Thx

Probably the most-common mistake is to fail to set the permissions of the .ssh directory (in the target user's home directory) to 700 = rwx------. If this is not the case, the contents of the directory (and therefore, your keys) will be ignored.

You do not have to restart sshd after making any such change.

When you attempt a password-free login, sshd looks for .ssh/authorized_keys in the target user's home, and checks that directory's permissions-mask.

You must also ensure that the connecting client is running a "ssh-agent" daemon, which actually supplies your key to the remote when you attempt to connect.

Great. By the way you can use more than one key and give each one a special purpose so they cannot be used for general login. See the "AUTHORIZED_KEYS FILE FORMAT" section in the manual page for "sshd". The part you would look for there is command="command"

If you don't mind telling, why are you using remote root access? There is often a better way.

Good luck here. The OP has been asking about doing this (and has received ANSWERS for it) for years now..you even answered one two years ago:
http://www.linuxquestions.org/questi...em-4175525156/
http://www.linuxquestions.org/questi...ts-4175525205/

And they've been advised numerous times to not log in as root.

LMAO. Good point. Now the OP has keys working, by 2018 or so they'll be able to leave remote root logins behind.