1

I have read a few times to disable root login and sudo as root using another user.

But is using a public key as good if not better security?

Kline
  • 247
  • 1
  • 5
  • 17
  • Nothing stopping you doing both. – Matthew Ife Dec 04 '14 at 11:10
  • I would say you should definitely use a public key to log in. And it is also a good idea to configure sshd to not allow any other authentication mechanism to log in. Next question is whether to ssh in as root, or to ssh in as another user and then use su or sudo to become root. There are arguments both ways. If you would ssh in as a non-root user at first and then become root, you may become exposed if that non-root user becomes compromised. See also: http://security.stackexchange.com/questions/66894/is-it-wrong-to-root-login-with-ssh – kasperd Dec 04 '14 at 11:25
  • It is also woth mentioning this question: http://serverfault.com/questions/617467/linux-console-login-with-screwed-up-home-permissions Somebody used ssh as non-root user and then sudo. But he messed up permissions so he could no longer ssh in as non-root. Having ssh directly as root might have helped in that case. – kasperd Dec 04 '14 at 11:31
  • There's a large number of [similar](http://serverfault.com/questions/137362) [questions](http://serverfault.com/questions/117570) and the side-bar with related questions lists even more. There are valid reasons to do as you ask and some counter arguments and risk mitigation that may be even more valid for your particular environment (for instance ssh access only on/from an already restricted management network and/or the presence of a well set up [privileged account management solution](http://en.wikipedia.org/wiki/Privileged_Identity_Management) ). – HBruijn Dec 04 '14 at 11:36
  • So what is it that a sudo root user can't do that the root user can? – Kline Dec 04 '14 at 13:51
  • You mean sudo *to* root, not *as* root? – psusi Dec 04 '14 at 14:27

2 Answers2

5

You should absolutely disable the ability to login as root remotely, and if at all possible also only allow login authentication to occur with the use of public/private key pairs (not password-only).

Have a look through this for best-practices on how to harden SSH (although this is provided as CentOS documentation, it applies in principal to any distribution under which you run sshd as your ssh daemon).

BE77Y
  • 2,667
  • 3
  • 18
  • 23
-1

You should disable root login for remote host, but enable it from localhost.

Here are the important lines of most of my openssh server config file:

PermitRootLogin yes # because of AllowUsers

PasswordAuthentication no # connexion allowed only with keys

AllowUsers user root@localhost

You can still connect into root by using the -A when connecting to your server as a simple user:

local $ ssh user@server -A

server $ ssh root@localhost

  • I'm not sure under what conditions you would want the localhost to be connecting to itself via ssh? – BE77Y Dec 04 '14 at 14:21
  • To connect as root from the server. – Michaël P. Dec 18 '14 at 12:19
  • ssh is a remote access method - not really for use locally! If you want to become the root user once you have connected as your own user, use the command `su - ` and enter the root password, or alternatively if your user has `sudo` capability, use the command `sudo su - ` and enter your own password. – BE77Y Dec 18 '14 at 12:26
  • The point of my method exposed bellow is to avoid the use of any password. To be root, you have to have your public key allowed for a user and for the root account. – Michaël P. Dec 18 '14 at 14:51
  • Very unconventional -you may be better placed using the `/etc/sudoers` file as per 'standard practices' under linux: this incorporates limiting per user/group as you seem to wish, and as for being challenged for a password, you could simply use a `NOPASSWD` directive on whichever user/group(s) you wish (this is well documented but there is a relevant post [here](http://www.ducea.com/2006/06/18/linux-tips-password-usage-in-sudo-passwd-nopasswd/). This is also significantly lighter on the administrative side of things (to get set up), than having to copy the root privkey to all necessary users. – BE77Y Dec 18 '14 at 14:58
  • In fact, it depends on the context you are working. In my case (lot of servers, several people working on it sharing the few accounts on each machine), these method is a good balance, between security and ease of use. I admit, it’s perhaps unorthodox. – Michaël P. Dec 18 '14 at 17:33