LFS211 Lab 5.3

MariaRalucaDiaconescu

Hi. I have a question related to practice. Should I log in to my root account with su to append using cat to /root/.ssh/authorized_keys?

It's still asking for the password after I try to ssh.

Maybe I did something wrong that I am not aware of.

MariaRalucaDiaconescu

I fixed this by restoring the permissions of the file /root/.ssh/authorized_keys to the other user than root. Is this ok?

KevinCSmallwood

Hi, you are referring to this step, correct? For security purposes, I would not change the owner of the files under /etc to a regular owner.

cat /home/student/.ssh/authorized_keys >> /root/.ssh/authorized_keys

In the Labs, you might see the '#' prompt used as opposed to '$'. The '#' prompt implies that this step needs to be performed as "root". You can login as "root," but this is highly discouraged, especially on production systems! Why? The main reason is that there is no accountability. If you are the only person who has the "root" password on that system, then it might be more acceptable. Otherwise, if several people have the "root" password, we don't know who is logged in as "root"; it could be a number of people, including someone who happened to break into your system! So, I recommend that you don't login as "root" on any production system. Your own desktop or Lab system, where you are the only user on that system, is acceptable, but not on a general purpose production system (except for single-user mode, of course). You can use the "su" command to get a "root" sub-shell. I recommend that you use "su -" since the lone hyphen will simulate a login, thus executing other dot-files as if the user that you switched to (in this case, "root") had logged in. You can also use the "sudo" command. On Distros like Ubuntu, you have to use "sudo" because the "root" user does not have a valid password! You can use "sudo -i" to give yourself an interactive "root" shell, similar to how "su" works, but without giving the "root" password. If you do want to use the "sudo" command, which is the safest and best accountable method to temporarily gain elevated privileged, there is a trick you have to do in order to do I/O redirection. If you just type, "sudo cat /home/student/.ssh/authorized_keys >> /root/.ssh/authorized_keys" it will not work correctly. Why? Because the shell you are in as a non-root user first sets-up the I/O redirection as the non-privileged user, and then executes the "sudo" command giving you alternate (in this case, "root") privilege. In order to do commands that include I/O redirection (as "root"), you need to do something like this:

$ sudo bash -c 'cat /home/student/.ssh/authorized_keys  >> /root/.ssh/authorized_keys'

What happens is that the "sudo" command is executing a "bash" sub-shell as "root" that then using the command after the "-c" that I put into quotes, that then executes the entire command, including the I/O redirection. This is what I call the "bash -c" trick. Note, it is only needed for I/O redirection. The following command in the Lab could be simply done as:

$ sudo chown root.root /root/.ssh/authorized_keys
$ sudo chmod 640 /root/.ssh/authorized_keys

As a Sys Admin, you will use the "bash -c" trick often. Good luck.

MariaRalucaDiaconescu

Thank you! I feel really honoured by this answer.