Learning ssh config
I added PermitRootLogin to ~/.ssh/config
Code:
host student1 Code:
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:
Code:
root@myserver:/etc/ssh# vi sshd_config Code:
root@myserver:/etc/ssh# /etc/init.d/ssh restart |
Quote:
and is liberally documented in the same file. |
You might find this a useful read
https://wiki.archlinux.org/index.php/Secure_Shell |
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.
|
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 Quote:
|
Quote:
There are separate manual pages for the server and the client. |
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. |
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! Quote:
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. |
Quote:
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.
|
Quote:
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 07:08 PM. |