Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
SSH via root
View unanswered posts
View posts from last 24 hours

Goto page 1, 2  Next  
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
grant123
l33t
l33t


Joined: 23 Mar 2005
Posts: 762

PostPosted: Sun Mar 02, 2014 2:41 am    Post subject: SSH via root Reply with quote

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?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32016
Location: 56N 3W

PostPosted: Sun Mar 02, 2014 10:01 am    Post subject: Reply with quote

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
Code:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1237
Location: 42.68n 85.41w

PostPosted: Sun Mar 02, 2014 10:09 am    Post subject: Reply with quote

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?????
_________________
cat /etc/*-release
Funtoo Linux - baselayout 2.2.0
consider this warning no. 1
https://wiki.gentoo.org/index.php?title=Special:Contributions/666threesixes666&offset=&limit=500&target=666threesixes666
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32016
Location: 56N 3W

PostPosted: Sun Mar 02, 2014 10:47 am    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4274

PostPosted: Sun Mar 02, 2014 1:12 pm    Post subject: Re: SSH via root Reply with quote

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.
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4274

PostPosted: Sun Mar 02, 2014 1:18 pm    Post subject: Reply with quote

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).
Back to top
View user's profile Send private message
Anon-E-moose
Advocate
Advocate


Joined: 23 May 2008
Posts: 2328
Location: Dallas area

PostPosted: Sun Mar 02, 2014 1:23 pm    Post subject: Reply with quote

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.
_________________
Asus m5a99fx, FX 8320 - amd64-multilib, 3.15.9-zen, glibc-2.17, gcc-4.7.3-r1, eudev
xorg-server-1.16, openbox w/lxpanel, nouveau, oss4
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8990

PostPosted: Sun Mar 02, 2014 4:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4131

PostPosted: Sun Mar 02, 2014 6:46 pm    Post subject: Reply with quote

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".
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 32016
Location: 56N 3W

PostPosted: Sun Mar 02, 2014 7:07 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
grant123
l33t
l33t


Joined: 23 Mar 2005
Posts: 762

PostPosted: Mon Mar 03, 2014 2:45 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
SirRobin2318
Apprentice
Apprentice


Joined: 24 Apr 2004
Posts: 213
Location: Strasbourg, france.

PostPosted: Mon Mar 03, 2014 2:54 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
grant123
l33t
l33t


Joined: 23 Mar 2005
Posts: 762

PostPosted: Mon Mar 03, 2014 5:34 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
SirRobin2318
Apprentice
Apprentice


Joined: 24 Apr 2004
Posts: 213
Location: Strasbourg, france.

PostPosted: Mon Mar 03, 2014 6:01 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1378

PostPosted: Mon Mar 03, 2014 6:13 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8990

PostPosted: Tue Mar 04, 2014 3:40 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1378

PostPosted: Tue Mar 04, 2014 4:05 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1378

PostPosted: Tue Mar 04, 2014 4:41 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
szatox
Guru
Guru


Joined: 27 Aug 2013
Posts: 371

PostPosted: Tue Mar 04, 2014 8:46 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
666threesixes666
Veteran
Veteran


Joined: 31 May 2011
Posts: 1237
Location: 42.68n 85.41w

PostPosted: Tue Mar 04, 2014 9:15 am    Post subject: Reply with quote

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.
_________________
cat /etc/*-release
Funtoo Linux - baselayout 2.2.0
consider this warning no. 1
https://wiki.gentoo.org/index.php?title=Special:Contributions/666threesixes666&offset=&limit=500&target=666threesixes666
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4131

PostPosted: Tue Mar 04, 2014 8:27 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1378

PostPosted: Wed Mar 05, 2014 1:44 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
BitJam
Advocate
Advocate


Joined: 12 Aug 2003
Posts: 2454
Location: Silver City, NM

PostPosted: Wed Mar 05, 2014 4:45 am    Post subject: Reply with quote

OpenSSH/Cookbook/Automated Backup says:
Quote:
It's a myth that remote root access must be allowed.
Back to top
View user's profile Send private message
grant123
l33t
l33t


Joined: 23 Mar 2005
Posts: 762

PostPosted: Wed Mar 05, 2014 11:03 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
1clue
Veteran
Veteran


Joined: 05 Feb 2006
Posts: 1378

PostPosted: Thu Mar 06, 2014 2:26 am    Post subject: Reply with quote

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.

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


By going here: https://en.wikibooks.org/wiki/OpenSSH/Cookbook/Automated_Backup#Backup_with_rsync_and_sudo
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum