LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Learning ssh config (https://www.linuxquestions.org/questions/linux-newbie-8/learning-ssh-config-4175594034/)

fanoflq 11-22-2016 09:18 AM

Learning ssh config
 
I added PermitRootLogin to ~/.ssh/config
Code:

host student1
        hostname localhost
        PermitRootLogin without-password
        user root

Then I did this:
Code:


[student@localhost .ssh]$ sudo systemctl restart sshd.service
[student@localhost .ssh]$ ssh student1
/home/student/.ssh/config: line 4: Bad configuration option: permitrootlogin
/home/student/.ssh/config: terminating, 1 bad configuration options
[student@localhost .ssh]$

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.

michaelk 11-22-2016 09:28 AM

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.

erik2282 11-22-2016 09:30 AM

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

Code:

root@myserver:/etc/ssh# vi sshd_config

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

Code:

root@myserver:/etc/ssh# /etc/init.d/ssh restart
[ ok ] Restarting ssh (via systemctl): ssh.service.


Habitual 11-22-2016 10:22 AM

Quote:

Originally Posted by fanoflq (Post 5633370)
Why is my ~/.ssh/config configuration incorrect?
What did I missed?
Thaanks.

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

DavidMcCann 11-22-2016 10:27 AM

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

suicidaleggroll 11-22-2016 10:27 AM

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.

fanoflq 11-22-2016 02:44 PM

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:

Code:

PermitRootLogin
without-password

Quote:

Addendum:

I stand corrected!!
It was discussed in /etc/ssh/sshd_config

Turbocapitalist 11-22-2016 02:51 PM

Quote:

Originally Posted by fanoflq (Post 5633514)
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.

szboardstretcher 11-22-2016 02:57 PM

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.

fanoflq 11-22-2016 03:00 PM

Thank you everybody.

Problem solved!

fanoflq 11-22-2016 03:20 PM

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!
Quote:

[user1@localhost .ssh]$ ssh root@server1
Last login: Tue Nov 22 10:01:13 2016 from localhost
[root@server1 ~]# exit
logout
Connection to server1 closed.
[user1@localhost .ssh]$

This looks like a weakness.
No?

szboardstretcher 11-22-2016 03:25 PM

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.

fanoflq 11-22-2016 03:53 PM

Quote:

Originally Posted by szboardstretcher (Post 5633534)
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?

michaelk 11-22-2016 04:00 PM

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.

suicidaleggroll 11-22-2016 04:22 PM

Quote:

Originally Posted by fanoflq (Post 5633547)
A key for non-root user should not be usable for root user.
No?

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.


All times are GMT -5. The time now is 12:53 AM.