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


Old Yesterday, 03:54 PM   #1

Member

 

Registered: Mar 2020

Posts: 547


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 Yesterday, 04:12 PM   #2

Moderator

 

Registered: Oct 2008

Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_12{.0|.1}

Posts: 5,655


Rep: Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689

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; Yesterday at 04:28 PM. Reason: typos, added prohibit root login

 

1 members found this post helpful.

Old Yesterday, 04:40 PM   #3

Member

 

Registered: Mar 2020

Posts: 547


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 Yesterday, 05:01 PM   #4

Moderator

 

Registered: Oct 2008

Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_12{.0|.1}

Posts: 5,655


Rep: Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689Reputation: 3689

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; Yesterday at 05:28 PM.

 

2 members found this post helpful.

Old Yesterday, 05:03 PM   #5

LQ Veteran

 

Registered: Feb 2013

Location: Tucson, AZ, USA

Distribution: CentOS 7.8.2003

Posts: 5,437


Rep: Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068Reputation: 2068

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; Yesterday at 05:06 PM.

 

2 members found this post helpful.

Old Today, 12:22 AM   #6

Member

 

Registered: Mar 2020

Posts: 547


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 Today, 12:36 AM   #7

LQ Guru

 

Registered: Apr 2005

Distribution: Linux Mint, Devuan, OpenBSD

Posts: 5,674


Rep: Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906

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 Today, 01:27 AM   #8

Member

 

Registered: Mar 2020

Posts: 547


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 Today, 01:55 AM   #9

LQ Guru

 

Registered: Apr 2005

Distribution: Linux Mint, Devuan, OpenBSD

Posts: 5,674


Rep: Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906Reputation: 2906

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 Today, 11:25 AM   #10

LQ 5k Club

 

Registered: Oct 2003

Location: Melbourne

Distribution: Slackware-current

Posts: 5,669


Rep: Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216Reputation: 2216

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.