LinuxQuestions.org
Download your favorite Linux distribution at LQ ISO.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 07-28-2021, 03:54 PM   #1
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Rep: Reputation: Disabled
ssh : diff login account, but same name@host.. why ?


I am learning ssh on KDE to remote ssh server.

I logged into a same remote shell using same local machine, but with 2 different shell account that i have made.
What confused me is that, both login are same name ? How come same login name ? displayed on # prompt of terminal ?

Code:
root@Roc:/# w
20:07:50 up 1 day, 13:28,  2 users,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/0    32.221.190.15    19:49   10:54   0.08s  0.08s -bash
User1    pts/1    32.221.190.15    19:37    0.00s  0.06s  0.00s w


root@Roc:~# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
user1:x:0:0::/home/user1:/bin/bash

Code:
login 1: 
---------
***(login as : root)***
root@Roc:/# whoami
root

root@Roc:~# cd
root@Roc:~#
Code:
login 2:
--------
***login as : user1 (with root privilege)***
root@Roc:~# whoami
root

root@Roc:/# cd
-bash: cd: /home/user1: No such file or directory
 
Old 07-28-2021, 04:12 PM   #2
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,269
Blog Entries: 24

Rep: Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196
Code:
root@Roc:~# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
user1:x:0:0::/home/user1:/bin/bash
...and this...

Code:
login 2:
--------
***login as : user1 (with root privilege)***
root@Roc:~# whoami
root
You cannot grant root privilege by setting the UID to zero in the passwd file. Doing so makes that user root - hence the system reports that user as root, not user1. Doing that only confuses the system and the user and potentially weakens other security measures and should never be done! It actually breaks your system in numerous ways.

If you want that user to be a separate user and to have root privileges then create the user account as a normal non-privileged user with a unique UID and home directory, then use sudo to grant specific root privileges, or use su to become root after login.

See man sudo and man su for details.

It is also a good idea to prohibit root user SSH login access anyway by setting PermitRootLogin No in the sshd configuration - especially important for internet facing systems.

Last edited by astrogeek; 07-28-2021 at 04:28 PM. Reason: typos, added prohibit root login
 
1 members found this post helpful.
Old 07-28-2021, 04:40 PM   #3
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
It is also a good idea to prohibit root user SSH login access anyway by setting PermitRootLogin No in the sshd configuration - especially important for internet facing systems.
That's exactly what i was trying to do.. I was trying to make an account with exact root privilege before i remove the root account.. for security sake. but .. maybe i did that wrong..
 
Old 07-28-2021, 05:01 PM   #4
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=15, FreeBSD_12{.0|.1}
Posts: 6,269
Blog Entries: 24

Rep: Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196Reputation: 4196
To be clear, the system only uses the UID to identify users, that is the third column in /etc/passwd:

Code:
root:x:0:0:root:/root:/bin/bash
user1:x:0:0::/home/user1:/bin/bash
The only time the user name is used is at login to find the corresponding UID.

In Linux and other Unix-like systems, the UID 0 has special meaning and is always what we refer to as the root user, but by any other name it is still the same user.

To accomplish your goal of blocking root access from what you now have, I would suggest the following:

1 - Login as root and delete the user1 account just to put things right. **
2 - Create a new non-privileged user, something like this: useradd -ms /bin/bash myuser
3 - Set the new user's password using the passwd function: passwd myuser
4 - Logout as root and try to login as new user: ssh myuser@myhost.com and verify they may become root: su - then whoami
5 - Assuming you became root, while there disable root SSH access by setting in sshd config (/etc/ssh/sshd_config on my system): PermitRootLogin No

You should now have non-privileged SSH access only with a user who may become root after login via the su - command!

For internet facing hosts I would suggest that you also learn about passwordless SSH login with secure certificate exchange as the only method - greatly enhances security and prevents the logs filling with password guesses!

Hope that helps!

Edit: Thanks to scasey for reminding us both - do not delete the root account. It is not necessary and does nothing for security, and only complicates many other actions - never a good idea. Do not delete it, instead think in terms of restricting access to it.

** If you try userdel user1 you will surely get an error because that user is still root! First edit /etc/passwd - very carefully, and change the UID of user1 to something not used on the system:

Code:
user1:x:0:0::/home/user1:/bin/bash
...change to ...
user1:x:77777:0::/home/user1:/bin/bash
Now userdel user1 should remove it.

Last edited by astrogeek; 07-28-2021 at 05:28 PM.
 
2 members found this post helpful.
Old 07-28-2021, 05:03 PM   #5
scasey
LQ Veteran
 
Registered: Feb 2013
Location: Tucson, AZ, USA
Distribution: CentOS 7.9.2009
Posts: 5,732

Rep: Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212Reputation: 2212
Quote:
Originally Posted by andrewysk View Post
That's exactly what i was trying to do.. I was trying to make an account with exact root privilege before i remove the root account.. for security sake. but .. maybe i did that wrong..
IMO it is not a good idea to “ remove the root account” … begs these questions:
Why do you want to do that? What problem are you trying to/think that will solve?

(Too slow…astrogeek’s advice is very through)

Last edited by scasey; 07-28-2021 at 05:06 PM.
 
2 members found this post helpful.
Old 07-29-2021, 12:22 AM   #6
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by scasey View Post
IMO it is not a good idea to “ remove the root account” … begs these questions:
Why do you want to do that? What problem are you trying to/think that will solve?

(Too slow…astrogeek’s advice is very through)
From what i read, remove root account so that for whoever tries to find an account to gain control of the host will have to go thru extra steps to look for an account that have root access. By default the account is "root". When i remove the "root" or make a root account without any privilege (just like normal user), then they will fool the "hacker" for a while..
That's the plan. I do think it makes some sense.
 
Old 07-29-2021, 12:36 AM   #7
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,326
Blog Entries: 3

Rep: Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726
That may be a misinterpretation of the general advice of removing remote root access. It is the remote access to the root account which is revoked, not the root account itself. In order to prevent direct access to the root account over SSH. See PermitRootLogin in /etc/sshd_config which will be described in the manual page "man sshd_config".

The workflow is then to log in to an unprivileged account via SSH and then either escalate to the root account using su for general actvities or use a carefully configured sudo for very specifically defined actions.
 
1 members found this post helpful.
Old 07-29-2021, 01:27 AM   #8
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Turbocapitalist View Post
It is the remote access to the root account which is revoked, not the root account itself.

The workflow is then to log in to an unprivileged account via SSH and then either escalate to the root account using su for general actvities
I see, not to remove the root account, but rather accessibilty of root account via ssh.

1 more question:
If i can ssh remotely into a normal user account to run "su", can't whoever the hacker also do that same ?
 
Old 07-29-2021, 01:55 AM   #9
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,326
Blog Entries: 3

Rep: Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726
In theory either a hacker or a cracker could do the same, but that adds at least two extra steps. That alone might be more than enough to prevent privilege escalation before detection. It also quiets the logs in that it removes the burden of having to analyze successfull remote root logins for whether or not they were legitimate and at the same time it provides a record of who to ask when something goes wrong or looks strange because people have to pass through their normal account first. The net result is saved effort for you and root access, if done competently, is no extra trouble.

No single step will prevent all trouble, but each layer will buy you time. The more layers intruders have to pass through, the less chance they have for a successful break in.
 
1 members found this post helpful.
Old 07-29-2021, 11:25 AM   #10
allend
LQ 5k Club
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware64-15.0
Posts: 6,374

Rep: Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754Reputation: 2754
Another layer is to have the server refuse all SSH connections, but have the server create a connection to your local machine with a cron job, so that you can use a reverse SSH tunnel from the local machine to access the server.
The downside is that the connection will only happen at the intervals set in the cron job.
 
1 members found this post helpful.
Old 07-30-2021, 01:36 AM   #11
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
To be clear, the system only uses the UID to identify users, that is the third column in /etc/passwd:

Code:
root:x:0:0:root:/root:/bin/bash
user1:x:0:0::/home/user1:/bin/bash
The only time the user name is used is at login to find the corresponding UID.

In Linux and other Unix-like systems, the UID 0 has special meaning and is always what we refer to as the root user, but by any other name it is still the same user.

To accomplish your goal of blocking root access from what you now have, I would suggest the following:

1 - Login as root and delete the user1 account just to put things right. **
2 - Create a new non-privileged user, something like this: useradd -ms /bin/bash myuser
3 - Set the new user's password using the passwd function: passwd myuser
4 - Logout as root and try to login as new user: ssh myuser@myhost.com and verify they may become root: su - then whoami
5 - Assuming you became root, while there disable root SSH access by setting in sshd config (/etc/ssh/sshd_config on my system): PermitRootLogin No

You should now have non-privileged SSH access only with a user who may become root after login via the su - command!

For internet facing hosts I would suggest that you also learn about passwordless SSH login with secure certificate exchange as the only method - greatly enhances security and prevents the logs filling with password guesses!

Hope that helps!

Edit: Thanks to scasey for reminding us both - do not delete the root account. It is not necessary and does nothing for security, and only complicates many other actions - never a good idea. Do not delete it, instead think in terms of restricting access to it.

** If you try userdel user1 you will surely get an error because that user is still root! First edit /etc/passwd - very carefully, and change the UID of user1 to something not used on the system:

Code:
user1:x:0:0::/home/user1:/bin/bash
...change to ...
user1:x:77777:0::/home/user1:/bin/bash
Now userdel user1 should remove it.
Hii,

I have done what you said above, your help is very detailed... Thanks.
I have got questions:
Q1.
How can the new user account "su" into root ? Does "ALL" user account capable of switching into "root" with "su" command ? **i asked this because i have my mentality that normal user should not be able to switch to root account with "su" command, else everybody shell user can do brute test on root account password and break into it.. since to take control of the whole shell is just A LINE separation - a root password.
I thought normal user have to be added into "admin or root group" in order to switch into "root account".

I just created a new normal user account on the remote shell.. but when i type "su" and i enter "root password" and it switched to "root account". when i typed "whoami" i got answer : "root"
When i typed "groups" it shows the same name as user account name.. It didn't shows that it is belong to root group or admin group; this shows the new normal user is not in "admin / root group".

Q2:
Since no need to be in "root / admin group", then what is the group good for ? why should a shell in a minimal user account environment need to bother about "group" ?
Example, a person who have the "privilege to do printing" need to be in a certain group; for example "tape group".


Thanks
 
Old 07-30-2021, 01:16 PM   #12
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by astrogeek View Post
To be clear, the system only uses the UID to identify users, that is the third column in /etc/passwd:

Code:
root:x:0:0:root:/root:/bin/bash
user1:x:0:0::/home/user1:/bin/bash
The only time the user name is used is at login to find the corresponding UID.

In Linux and other Unix-like systems, the UID 0 has special meaning and is always what we refer to as the root user, but by any other name it is still the same user.

To accomplish your goal of blocking root access from what you now have, I would suggest the following:

1 - Login as root and delete the user1 account just to put things right. **
2 - Create a new non-privileged user, something like this: useradd -ms /bin/bash myuser
3 - Set the new user's password using the passwd function: passwd myuser
4 - Logout as root and try to login as new user: ssh myuser@myhost.com and verify they may become root: su - then whoami
5 - Assuming you became root, while there disable root SSH access by setting in sshd config (/etc/ssh/sshd_config on my system): PermitRootLogin No

You should now have non-privileged SSH access only with a user who may become root after login via the su - command!

For internet facing hosts I would suggest that you also learn about passwordless SSH login with secure certificate exchange as the only method - greatly enhances security and prevents the logs filling with password guesses!

Hope that helps!

Edit: Thanks to scasey for reminding us both - do not delete the root account. It is not necessary and does nothing for security, and only complicates many other actions - never a good idea. Do not delete it, instead think in terms of restricting access to it.

** If you try userdel user1 you will surely get an error because that user is still root! First edit /etc/passwd - very carefully, and change the UID of user1 to something not used on the system:

Code:
user1:x:0:0::/home/user1:/bin/bash
...change to ...
user1:x:77777:0::/home/user1:/bin/bash
Now userdel user1 should remove it.
I think you missed out "restart host" for the sshd modification to take effect..
I have edited ssdh_config and tried "root login" .. it still able to login without problem.. then i restarted the host system and root no longer able to ssh in.
 
Old 07-30-2021, 01:27 PM   #13
Turbocapitalist
LQ Guru
 
Registered: Apr 2005
Distribution: Linux Mint, Devuan, OpenBSD
Posts: 7,326
Blog Entries: 3

Rep: Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726Reputation: 3726
Quote:
Originally Posted by andrewysk View Post
I have edited ssdh_config and tried "root login" .. it still able to login without problem..
Yes, restarting the whole host will do it, but a less extreme way would be to just restart the SSH daemon. Or even just sending a HUP via kill to sshd would be enough to have it reload its configuration file. That's one of those kind of things which goes without saying and thus went unsaid.
 
1 members found this post helpful.
Old 07-30-2021, 01:44 PM   #14
computersavvy
Senior Member
 
Registered: Aug 2016
Posts: 3,345

Rep: Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484Reputation: 1484
On EVERY system the "su" command will allow any user to switch to root. This is why it is mandatory that either the root account be disabled or that there be a very secure password used so only the administrator has access.

BTW, just so you know.
If I have physical access to your machine I can get access as root, regardless of how secure the password is. It does not matter how many road blocks you put in the way, there is always the possibility to get past them.

This is why any security procedure requires multiple layers that an attacker must get past, and the physical access is only one of those.
 
Old 07-30-2021, 01:53 PM   #15
andrewysk
Member
 
Registered: Mar 2020
Posts: 797

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by computersavvy View Post
On EVERY system the "su" command will allow any user to switch to root. This is why it is mandatory that either the root account be disabled or that there be a very secure password used so only the administrator has access.

BTW, just so you know.
If I have physical access to your machine I can get access as root, regardless of how secure the password is. It does not matter how many road blocks you put in the way, there is always the possibility to get past them.

This is why any security procedure requires multiple layers that an attacker must get past, and the physical access is only one of those.
Just to let myself a clear understanding of the whole concept ..
If you disable root account, so now "su" no longer working.. but anybody can still use "sudo" to do a lot of stuff (damage) ... or rather all the stuff "root account" can do.
Further more, anybody who have "sudo" access can use "sudo" to "enable" root account back... .. so... what's is the point of "remove root account" ?

Btw, "sudo" does not use "root account password" right ? only "su" uses root account password.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SSH - How can I only allow a key pair login for my user account not root account? shanekelly Linux - Security 5 01-25-2013 09:45 AM
at same directory, is it cannot have same name text file and folder name? hocheetiong Linux - Newbie 6 11-10-2007 10:20 AM
Why is my common account can't open Terminal in XFCE4 but root account? notsay Slackware 4 08-18-2007 11:29 PM
is it legitimate and allowed and can be done to make another user account set uid and gid to null 0 to make another root account with different name and possibly not damage the debian system creating and using that new account BenJoBoy Linux - Newbie 12 01-29-2006 10:02 AM
the mail account name must be login name ? LCD Linux - Software 0 03-19-2003 04:37 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 04:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration