Usually on Linux there is only one user root
, and on Ubuntu it is deactivated. Instead it is a better idea to add all users that should have administrative privilieges to the group sudo
by executing
adduser username sudo
as root. That allows them to execute commands as root by typing
sudo command
and get a root shell by
sudo -i
On top op that, you don't have to enable root login for ssh that way.
The home directory probably wasn't created because you added a user with an id (0
) that already existed. Avoid setting the userid and groupid manually.
Step-by-Step how-to create an admin user:
sudo adduser username
sudo adduser username sudo
No, disabling SSH access in the sshd_config
file will not affect the ability to login locally or through the use of su
command.
Although you can limit the accounts allowed to connect with SSH as described in the referenced answer (i.e. by setting either DenyUsers specadmin
or AllowUsers mary
in the /etc/ssh/sshd_config
file), it would still be less secure than what is considered a common practice for SSH.
You should not go that way and instead switch to the key-based authentication.
If you are configuring it for the first time, it might seem cumbersome, but as you use cloud services, you can easily add a new server and perform test runs (btw, cloud services usually give you a web access to the console if you lock yourself out).
First you should set (or ensure the following options is set in the sshd_config
):
PubkeyAuthentication yes
Then you should generate a key-pair on your client machine (ssh-keygen
command on Linux machines) and add the public key to the following file (for mary
):
/home/mary/.ssh/authorized_keys
either by copying manually (a key is a string of characters) or using ssh-copy-id mary@<destination_server>
command which will upload the key automatically.
You should be able to connect to the server using ssh mary@<destination_server>
using the key. If you set the passphrase during ssh-keygen
, which you should, you will need to enter it, but it will not be transferred between the client and the server. To be really sure you are doing things correctly set a passphrase to the key file different from the password on the destination server.
If you can successfully login using the key authentication (and passphrase), you can proceed to disabling password based one by adding/ensuring the following settings in sshd_config
:
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
HostbasedAuthentication no
After the changes to the sshd_config
you should of course restart the SSH daemon (sudo service ssh restart
) on the server.
For peace of mind you might also want to disallow access via SSH for the root account in the sshd_config
(although if you perform the above, root won't be able to login by default):
PermitRootLogin no
Best Answer
Edit (as root)
/etc/ssh/sshd_config
. Append the following to it:Port 1234
causes SSH to listen on port 1234. You can use any unused port from 1 to 65535. It's recommended to choose a privileged port (port 1-1024) which can only be used by root. If your SSH daemon stops working for some reason, a rogue application can't intercept the connection.PermitRootLogin
disallows direct root login.AllowUsers jim
allows userjim
to login through SSH. If you do not have to login from everywhere, you can make this more secure by restricting jim to an IP address (replace 1.2.3.4 with your actual IP address):Changes to the configuration file
/etc/ssh/sshd_config
are not immediately applied, to reload the configuration, run: