Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have centos5.

Is there any way that i can log into my vps server with root user from particular ip address only.

I have read that i can use private key to login into sshd. But the problem is i am using SFTP for all my webistes and i don't want non IT users to use keys to login with SFTP.

OR is there any way that only root can use keys to login into shell but for others its normal password

share|improve this question

It is generally a better practice to log in as a non-privileged user first then use 'su -' or 'sudo' to gain root privileges, but...

You could always put the IP restriction on your key in ~root/.ssh/authorized_keys:

from="" ssh-rsa AAAAh9uif...auwehuf==

This would allow ssh using the key only from

share|improve this answer

A better way now is to use the Match keyword:

Match Host myworkstation
        PermitRootLogin yes


Match Address
        PermitRootLogin yes

That way, you can leave PermitRootLogin set to 'no', but you can still log in as root from your workstation.

This can also be used, for example, to allow root to rsync data between two hosts.

share|improve this answer


PermitRootLogin without-password

In /etc/ssh/sshd_config. Every user excluding root will be allowed to use password logins. Root needs to use keys to login.

share|improve this answer
Will this slution work?? did u tried this – John Oct 17 '10 at 2:13
I use that setting in every server I maintain. It prevents root bruteforce/dict attacks. – rubiojr Oct 17 '10 at 22:12

Edit sshd_config (usually in /etc/ssh), and add or change the following directives

  PermitRootLogin yes
  AllowUsers root@thehosttoallow

Then restart the daemon

  service ssh restart
share|improve this answer
I believe that, if the OP wanted to use AllowUsers, he would need to specify all users he want to have access. Your example would only allow root to authenticate via ssh. – EEAA Oct 11 '10 at 0:40
Yes, this is on purpose. To allow any user, *@thehosttoallow indeed let any user in. – ringø Oct 11 '10 at 0:43

First, why would you want to prevent users from using key auth? That makes no sense to me.

Second, don't allow root login via ssh. Just don't do it - there's no good reason for needing to do so. It goes against every best practice out there, and for good reason. If you need to grant permissions to read/write certain files, you should be able to do so through the standard linux filesystem permissions. If you need more fine-grained access control, look into the linux ACL system.

share|improve this answer
what if i disable root login and neither of any user has access to some main config file. Then i am locked as i can't login via root – John Oct 11 '10 at 0:33
When you disable root login via ssh, root will still be able to sign in via the console. Also, you always have the option of granting a normal user root-esque permissions via sudo. This won't work for sftp, but as a failback in case you need to fix things, it would work fine and is the preferred way of granting permissions. – EEAA Oct 11 '10 at 0:36
@ErikA Allowing root from a unique host is not unsafe. There was a trend against the root access via telnet a few years back (besore ssh was common), but allowing root via ssh to only one host doesn't look that unsafe. – ringø Oct 11 '10 at 0:41
Sure, it may perhaps be "safe", but I'll still argue that it's a poor idea. I say this mainly due to the fact that, when people are given an easy way to get root access, they will use it, rather than using a safer, more proper way to gain access (sudo). – EEAA Oct 11 '10 at 1:17
Considering the author question, one can assume he wants to perform administrative tasks through the root user. Allowing direct root access from only one host in this case is a reasonable alternative. – ringø Oct 11 '10 at 4:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.