I added PermitRootLogin to ~/.ssh/config
Then I did this:
One problem I found was permitrootlogin does not exists in man ssh_config, but it is mentioned in man ssh.
WHY?

Why is my ~/.ssh/config configuration incorrect?
What did I missed?
Thaanks.

The client and the server have different configuration files. The /etc/ssh/ directory contains the server configuration file i.e. sshd_config which uses the PermitRootLogin directive. It also contains the system wide client configuration file i.e ssh_config. In addition you can also have a users client configuration file i.e ~/.ssh/config. The directives are not the same for the server and client.

For security purposes you should not enable Root login or at least only use keys.

If you're trying to permit root login over ssh, then you need to edit /etc/ssh/sshd_config to look like this:

PermitRootLogin goes in /etc/ssh/sshd_config
and is liberally documented in the same file.

2 members found this post helpful.

You might find this a useful read
https://wiki.archlinux.org/index.php/Secure_Shell

1 members found this post helpful.

PermitRootLogin wouldn't work too well as a security feature if the client could turn it off in their config file. What would be the point? That's a server config option, not a client config option. The server config is at /etc/ssh/sshd_config, is only editable by root, and applies to incoming connections to that machine. The client config is at /etc/ssh/ssh_config, and per-user options are in ~/.ssh/config, they control how you connect to other machines.

1 members found this post helpful.

Thank you for all the posts, folks.

I like to mention that I was not able to find
much usable information on these words in man ssh_config
or man ssh:

That's because they deal with the client. The permissions you are looking for are managed over on the server. See man sshd_config and man sshd instead. You'll find those words / configuration directives there instead.

There are separate manual pages for the server and the client.

1 members found this post helpful.

NOTICE: sshd_config NOT ssh_config

As mentioned:

sshd_config is the global ssh SERVER configuration
ssh_config is the global ssh CLIENT configuration

"PermitRootLogin yes" allows root to ssh to the server. It does exactly what it's name says. Not much documentation needed for it.

Are you attempting to allow root to log in without a password or a key? You shouldn't do that. If needed, you should 'PermitRootLogin' then set up a passwordless ssh key for the root user.

1 members found this post helpful.

Thank you everybody.

Problem solved!

Just thought I mention this observation.

Say on our remote machine, We created a ssh key via ssh-keygen.
Now we can ssh into server like so: ssh student@server1

And you see it works when it did not ask
for student's password after the first ssh login.

Then we copy to server via ssh-copy-id.
We can then ssh into server1 without password.

Now, on our remote machine, we copy from
/home/user1/.ssh/authorized_keys to /root/.ssh/

If we ssh like so, it would work for root also
without needing root's password!
This looks like a weakness.
No?

Well - if you hadn't copied the authorized_keys file to the root/.ssh directory you wouldn't be able to log in as root. How is that a weakness? Seems like a purposeful action that can be avoided.

ie: dont do that if you dont want that outcome.

A key for non-root user should not be usable for root user.
No?

As long as the keys match you can copy them to any user on either client or server and be able to login without a password. If you have root's password or sudo privileges to everything you can do whatever you want regardless... As stated don't permit root login.

1 members found this post helpful.

I don't know what you mean.

Keys come in pairs. A client generates a private/public key pair for user1 on machine1. That public key can then be copied to any user on any server (let's call it user2 and machine2), in order to allow user1@machine1 to connect to user2@machine2 without a password. There's no reason you can't copy that public key to user3@machine2 as well, to allow user1@machine1 to ssh to either user2 or user3@machine2. Whether user1, user2, or user3 are regular unprivileged users or root is irrelevant. If you don't want user1@machine1 to be able to ssh into userX@machineX, then don't stick their public key in the authorized_keys file. It's also a good idea to disable ssh access for root, period, whether or not the client has a valid key.

2 members found this post helpful.