# SSH via root

## grant123

Can I configure SSH to allow password access for one user and keys access for root?

Can I have SSH root access require a password and keys?

----------

## NeddySeagoon

grant123,

Any ssh access for root it doing it wrong.

Add users you want be be able to gain root access to the wheel group and install and set up sudo.

Users in the wheel group can now do 

```
sudo su -
```

and give their own password to become root with roots environment.

If you enable both key based and password based logins, ssh will prefer keys and fall back to passwords.

----------

## 666threesixes666

neddy are you endorsing sudo and disabling root login system wide?  as outlined in the sudo talk page found here https://wiki.gentoo.org/wiki/Talk:Sudo#SUDO_VOODOO?????

----------

## NeddySeagoon

666threesixes666,

I disable remote access for root an all my systems but permit console access for root.

I can't remember the last time I used a root login (I've forgotten my root passwords).

To log in via ssh an attacker needs two things, a user name and a password.

If root logins are permitted, the attacker already has 50% of the information to log in. 

In my opinion, making wheel group users sudo nopasswd is a step too far.

When I do the odd root command with sudo command, I like the reminder that the password prompt provides.

Its no extra security, since an attacker that is in a wheel users account already has a password collision.

----------

## krinn

 *grant123 wrote:*   

> Can I configure SSH to allow password access for one user and keys access for root?

 

You can enable both password and key access, as ssh try always key prior to password, having a valid key for root and none for the user will make it key access for root and by password only for user.

If you're going for keys only for root and password only for user, then i don't know, as invalid key for root will backup to password access for root.

----------

## krinn

 *NeddySeagoon wrote:*   

> 
> 
> To log in via ssh an attacker needs two things, a user name and a password.
> 
> If root logins are permitted, the attacker already has 50% of the information to log in. 
> ...

 

But the numbers are flow because of the strength of the next 50% part of the problem :

root account is known but its password is certainly stronger than a random user.

and from what i see in my own log, people prefer trying to guess a user name that would then allow them to bet on a weak password than attacking the root itself.

Sure one could use 12356 as password for root, but people put their bet to met it more with "pamela" account than root one. (no offense to any pamela's mind here, that's an example).

----------

## Anon-E-moose

For the most part, I keep ssh locked to only access for the local network.

I have gone out of town and visited people, and when that happened, 

I took the time to try and look at the range of IPs that would be available and set it up to allow only those.

I'm in the USA, I certainly wouldn't set up potential access for use outside this country.

I know everybodies different, but there are other things to do to tighten up security.

----------

## Hu

When using sudo, I prefer sudo -i over sudo su -.  It is shorter and both result in an interactive root shell, assuming the right password and permissions.

For requiring keys for root, sshd has the special option PermitRootLogin without-password, which prohibits password-based root authentication.

----------

## mv

 *NeddySeagoon wrote:*   

> Any ssh access for root it doing it wrong.

 

I don't agree: root access is the only way to allow rsync for all files without jumping loops.

 *Quote:*   

> If root logins are permitted, the attacker already has 50% of the information to log in.

 

I would say: If this gives 50% of the information then you are doing something wrong.

More precisely, a typical user name is 6 symbols, all lowercase, which means 3-4 bytes of actual informatino. For any secret (no matter whether it is a password or a shared key), adding 3-4 bytes redundancy to the data can hardly change it from "insecure" to "secure". Using a longer key instead should add much more to your security than 3-4 bytes. Considering the username as part of the secret is just "security by obscurity".

----------

## NeddySeagoon

mv,

 *Quote:*   

> If this gives 50% of the information then you are doing something wrong

 

You are correct. If you consider the username  and password/key as part of the single secret needed to log in, the username is only a small part of the secret.

----------

## grant123

 *Quote:*   

> I don't agree: root access is the only way to allow rsync for all files without jumping loops. 

 

Exactly, that's what I'm doing.  I wish I could require both keys and a password for root.

----------

## SirRobin2318

You can password protect your ssh keys when you generate them. So your sshd conf would only allow key authentication, but on the client side, when using that key, you'd be required to enter a password to unlock it.

----------

## grant123

So if I configure the server with 'PermitRootLogin without-password' and specify a password when generating the keys, the client would be required to have the private key and enter the password when connecting?  This password prompt is just like the normal SSH password prompt?

----------

## SirRobin2318

Yes, that's it. Give it a try to see if it works as intended. Note that the client can have ssh-agent to remember the password.

----------

## 1clue

Try changing the port of sshd.  Put it in the 5-digit range for ports, which basically means nobody is going to scan that high.  IMO the absolutely biggest security hole in ssh is a default port.

I would go through any amount of effort to not allow root login from remote under any circumstance, for any reason.  Sudo is enough.  There are two things I really like about Ubuntu:  The first is disabled root account.  You can't even log in as root on the terminal.  The second is that you can install it in about 5 minutes, but that's not part of this discussion.  The presence of a root account which can be used as login is a security nightmare for any IT shop.  When somebody gets fired, what you gonna do?  Change all root passwords on all the UN*X boxes?  That's not rational.

Root login having better passwords:  I call BS on that.  Root login has no forced password validation.  I know several people who use 2 or 3 character passwords for root, and in one case I know both characters are on the home row.  Worse yet, this is a business network, and he uses "some two-character combination on the home row" for all his accounts on that network, and had done so for several years.  Or i should qualify:  He did when I worked with him, and since that was a few years back he might have changed his behavior since.

I've ranted at people for bad passwords for my entire professional IT carreer, which started in the mid 90s.  The only way they'll ever change their behavior is to be owned in a huge way with big consequences ($$$), where their bad security is the only possible explanation.

----------

## Hu

 *1clue wrote:*   

> I would go through any amount of effort to not allow root login from remote under any circumstance, for any reason.  Sudo is enough.

 As already stated above, sudo is not enough in some cases.  I know of no way to allow privileged rsync using sudo to elevate the remote side.

 *1clue wrote:*   

> There are two things I really like about Ubuntu:  The first is disabled root account.  You can't even log in as root on the terminal.  The second is that you can install it in about 5 minutes, but that's not part of this discussion.  The presence of a root account which can be used as login is a security nightmare for any IT shop.  When somebody gets fired, what you gonna do?  Change all root passwords on all the UN*X boxes?  That's not rational.

 I consider sudo to be a security weakness for the fact that it reuses the individual account password as an authorization password.  Changing the root password is not your biggest problem.  Your biggest problem is that someone who had privileged access to do anything to the systems is now gone under bad terms.  If the now ex-employee had no ill intent, you could leave the root passwords unchanged and it would not matter.  If he had ill intent, he could have arranged any number of backdoors or time bombs on the system.

----------

## 1clue

 *Hu wrote:*   

>  *1clue wrote:*   I would go through any amount of effort to not allow root login from remote under any circumstance, for any reason.  Sudo is enough. As already stated above, sudo is not enough in some cases.  I know of no way to allow privileged rsync using sudo to elevate the remote side.
> 
> 

 

I'm not convinced that a wrapper script on the remote end couldn't handle that.

 *Quote:*   

> 
> 
>  *1clue wrote:*   There are two things I really like about Ubuntu:  The first is disabled root account.  You can't even log in as root on the terminal.  The second is that you can install it in about 5 minutes, but that's not part of this discussion.  The presence of a root account which can be used as login is a security nightmare for any IT shop.  When somebody gets fired, what you gonna do?  Change all root passwords on all the UN*X boxes?  That's not rational. I consider sudo to be a security weakness for the fact that it reuses the individual account password as an authorization password.  Changing the root password is not your biggest problem.  Your biggest problem is that someone who had privileged access to do anything to the systems is now gone under bad terms.  If the now ex-employee had no ill intent, you could leave the root passwords unchanged and it would not matter.  If he had ill intent, he could have arranged any number of backdoors or time bombs on the system.

 

Sudo is certainly no more risky than a shared root password.  For one thing, with a shared root password you have no way to find out who it was who originally instigated some sort of bad behavior.  And with sudo, you can shut down the bad guy before he has a chance to fire off a trigger to all those time bombs.  Backdoors are a risk in either case.

I guess in my experience, I've never seen any evidence of premeditated time bombs on company equipment.  I worked with a guy who claimed he had, but he liked to blow steam every now and then, and bragging that sort of thing in a break room belies the cleverness of putting in those bombs.

Another benefit of sudo is the ability to provide limited access rather than all or nothing.

The sudo debate has been going on for forever.  I'm sold on it, and you're not.  Let it rest there.  We could get back on topic that way.

----------

## 1clue

Sorry for the double post.  I hadn't really finished my thought.

Premeditated time bombs:  In my experience, the IT guy who gets fired is usually either lazy and doesn't do enough (not likely to bother with a back door or time bomb), or not clever enough (no chance of a real back door or time bomb) or suddenly snaps and gets nasty all of a sudden.

I'm not saying premeditated boobytraps are impossible, but rather that doing something like that is illegal at best and criminal in the right circumstances.  And probably traceable if you're using sudo.

Unlimited rsync:  I can't help but think that if you need this, you're doing it wrong.  Allowing rsync to access any file on the system just seems like an invitation to black hats.  Backups?  Start it on the client and upload a file with an unprivileged account.

----------

## szatox

 *grant123 wrote:*   

>   I wish I could require both keys and a password for root.

 

1) disable remote login on root

2) force passwor-less login on user (I suppose it's possible to force it on a particular group only, in case you needed pasword login as well)

3) Login on user account with key

4) use either su or sudo to get root priviliges

So, you need user key and either user pasword or root password to login as root.

Now, key alone should be secure enough to make password expendable, and breaking standards is just a bad idea. Don't change ssh port, use tools you already have.

----------

## 666threesixes666

i was experimenting with pam today to throttle root failed login attempts.  problem with what i was doing was it would lock everyone out of root, not specific ip addresses or what ever....  keys could still get in, and sudo su could still get in, but su was completely barred of entry.  i have the clues and pieces to wrap together some sort of policy but i haven't really thought through what should be done with that if anything at all.  personally i believe passwd -l root is a superior answer to what pam trys to address.  i agree with 1clue about sudo.

ive been playing with the idea of 

1. powerless user with ssh keys to login as sudo user

2. sudo user with no password set.

3. sudo su to get to root which also has no password login options.

or powerless user with keys to root user.

auth		required	pam_tally2.so deny=3 unlock_time=30 even_deny_root

added to  /etc/pam.d/system-auth for my experiments.

idk, jailing ssh with fail2ban might be something for you to investigate.

----------

## mv

 *1clue wrote:*   

>  *Hu wrote:*   As already stated above, sudo is not enough in some cases.  I know of no way to allow privileged rsync using sudo to elevate the remote side. 
> 
> I'm not convinced that a wrapper script on the remote end couldn't handle that.

 

If you really know how to do this "cleanly" (without hacking your version of rsync or something similar), I would be interested to know: AFAIK, rsync just executes rsync over ssh with some magic parameters on the remote host. Of course, you could put a "fake" rsync into the path which somehow checks whether it is called remotely and then executes the "original" rsync eiither plainly or via sudo, but this is a rather nasty hack (requiring e.g. that this user can execute sudo for rsync without being asked for a password) so that I have some doubts that this is more secure than if you login "cleanly" as root.

----------

## 1clue

 *mv wrote:*   

>  *1clue wrote:*    *Hu wrote:*   As already stated above, sudo is not enough in some cases.  I know of no way to allow privileged rsync using sudo to elevate the remote side. 
> 
> I'm not convinced that a wrapper script on the remote end couldn't handle that. 
> 
> If you really know how to do this "cleanly" (without hacking your version of rsync or something similar), I would be interested to know: AFAIK, rsync just executes rsync over ssh with some magic parameters on the remote host. Of course, you could put a "fake" rsync into the path which somehow checks whether it is called remotely and then executes the "original" rsync eiither plainly or via sudo, but this is a rather nasty hack (requiring e.g. that this user can execute sudo for rsync without being asked for a password) so that I have some doubts that this is more secure than if you login "cleanly" as root.

 

What's your objective?  Are you just syncing two systems?  Without knowing the project, I can't help much.

My main argument is that syncing an entire system isn't really all that great an idea.  I have ALWAYS found a way to avoid it, meaning that I haven't ever actually done a full system transfer.  You're sending security information and everything over the wire.

If you want to rsync system A's entire contents to system B, then start it from A as root, write it to system B as an unprivileged user into an excluded directory on B which does not exist on A.  Then as root on B, sync from that to system B in its original location.

----------

## BitJam

OpenSSH/Cookbook/Automated Backup says: *Quote:*   

> It's a myth that remote root access must be allowed.

 

----------

## grant123

 *1clue wrote:*   

> You're sending security information and everything over the wire.

 

But rsync encrypts via ssh, right?

 *1clue wrote:*   

> If you want to rsync system A's entire contents to system B, then start it from A as root, write it to system B as an unprivileged user into an excluded directory on B which does not exist on A. Then as root on B, sync from that to system B in its original location.

 

How can you write permissions/ownership info correctly as an unprivileged user?

----------

## 1clue

 *grant123 wrote:*   

>  *1clue wrote:*   You're sending security information and everything over the wire. 
> 
> But rsync encrypts via ssh, right?
> 
>  *1clue wrote:*   If you want to rsync system A's entire contents to system B, then start it from A as root, write it to system B as an unprivileged user into an excluded directory on B which does not exist on A. Then as root on B, sync from that to system B in its original location. 
> ...

 

By going here:  https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Automated_Backup#Backup_with_rsync_and_sudo

----------

## BitJam

That's the link I posted earlier in this thread.

----------

## 1clue

Yes, sorry I didn't give proper attribution, but I thought it was obvious since it was only a couple posts up.

And another thing, whether rsync encrypts by ssh or not isn't as important as the fact that you have allowed ssh to the root account.

All this talk about the username being irrelevant or almost irrelevant doesn't take into account that it's a default account, and it's the superuser account, and if you can brute force that you have all rights.  So any brute force scheme makes more sense if it throws most of the resources against the root account.

If you set your user so they can only sudo rsync, then that eliminates some of the security woes of the bad guys cracking the unprivileged account.  I believe that link shows how.

----------

## grant123

What about root SSH access via passworded keys and 'PermitRootLogin without-password'?  That must be pretty safe.

----------

## 1clue

Look.  It's your box, but the doc you were pointed at proves that root access across the wire is unnecessary.

You obviously haven't had a production system owned yet.  I have.  Several times, fortunately nothing that cost a lot of money to fix.  The thing I learned is you always try to minimize the risk.

RSyncing an entire system across the wire, why?  What does that get you?

Root access across the wire, it's not necessary.  Why?  What does that get you?

Defense in depth.  Never leave your security to a single layer.  If your system can be owned through a single vulnerability in something you know, then that's no good.

So you want to rsync as root.  Go ahead, it's your box and hopefully you're not storing any financial information on there.  You could get away with it for years, or you could get owned the first day.  I've said all I can to point you in a safer direction, it's up to you now.

Have fun.

----------

## grant123

 *Quote:*   

> Defense in depth. Never leave your security to a single layer. If your system can be owned through a single vulnerability in something you know, then that's no good. 

 

So the vulnerability in this case would be someone breaking into my personal system, stealing my private key, and bruteforcing it to get the password?

 *Quote:*   

> hopefully you're not storing any financial information on there

 

Nope, nothing like that.

----------

## 1clue

 *grant123 wrote:*   

>  *Quote:*   Defense in depth. Never leave your security to a single layer. If your system can be owned through a single vulnerability in something you know, then that's no good.  
> 
> So the vulnerability in this case would be someone breaking into my personal system, stealing my private key, and bruteforcing it to get the password?
> 
>  *Quote:*   hopefully you're not storing any financial information on there 
> ...

 

The vulnerability that gets you is the one you don't know, not just the ones you can think of.  Getting access to a private key is an obvious one.

Overly authorized accounts making or allowing network connections are vulnerable.  Why do you think services change the user to some account that can't even log in?  Why go through the trouble, if there were no risk?  Why do services chroot into a jail AND change to an unprivileged user who can't log in if there were no risk?

----------

## 1clue

And what's the deal anyway?

You've been given step-by-step instructions on how to do this without allowing remote root login, and you still want to do it with remote root login?  What possible motivation could there be?

I wish you the best of luck.

----------

## mv

 *1clue wrote:*   

> If you want to rsync system A's entire contents to system B, then start it from A as root, write it to system B as an unprivileged user into an excluded directory on B which does not exist on A.  Then as root on B, sync from that to system B in its original location.

 

This is what I meant by "jumping loops": A transfer of data is possible, but not really in an "rsync" way (by "quickly" showing you the new/old/changed files, transferring only new data etc) - more or less you can do only the same as you could do only with tar and scp.

I have to travel a lot and make various changes on various systems, so after a while I have to sync various data of different users (or sometimes global data/config-files) between both directions on several machines - typically, I do not remember which changes I made and want to transfer, so using the mentioned rsync features is really "mandatory".

When syncing, the connection is typically only local, so security is not a concern in this moment (but I think it would be the same for non-local connections since I suppose that ssh can be considered reasonably safe).

 *Quote:*   

> By going here: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Automated_Backup#Backup_with_rsync_and_sudo

 

I consider this information rather nonsense: If you setup a user who can use "sudo" (at least with the privileges to read/modify all files) without a password you can allow root access as well - the latter has the advantage that ssh easily allows to "block" password access for root (which was the original quesiton of this thread).

----------

## grant123

 *Quote:*   

> You've been given step-by-step instructions on how to do this without allowing remote root login, and you still want to do it with remote root login? What possible motivation could there be?

 

Simplicity is the motivation.  Security is paramount but there is a tradeoff between that and simplicity.  I will delve into the sudo stuff but we shouldn't pretend that the tradeoff isn't important.

----------

