Linux users allowed to login

Which users are allowed to log in via SSH by default?

Thus, login via ssh would only work for users that have a populated password field in /etc/shadow or an ssh key in ~/.ssh/authorized_keys . Note that the default value for PubkeyAuthentication is yes and for PermitEmptyPasswords is no , so even if you remove them the behavior will be the same.

In the question example, www-data by default won’t be allowed to log in since Debian’s installer neither assigns a password nor creates a key for www-data .

pam_access , AllowUsers and AllowGroups in sshd_config can be used for finer control if that’s needed. In Debian it’s strongly encouraged to UsePAM .

By default, login is allowed for all users on Debian.

You can change it by allowing certain users that can log into by editing /etc/ssh/sshd_config file.

As mentioned in the man page of sshd_config.

AllowUsers

This keyword can be followed by a list of user name patterns, separated by
spaces. If specified, login is allowed only for user names that match one of the patterns. Only user names are valid; a numerical user ID is not
recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. The allow/deny directives are processed in the following order: DenyUsers , AllowUsers , DenyGroup , and finally AllowGroups .

I added «on Debian» in case someone comes along and reads the question title and answer without reading the question itself. The general answer to the question title is, «it depends on the contents of the shipped sshd_config file.» Some OSes ship with root login over SSH disallowed, for example.

Thanks, but obviously by default only root can login since he’s the only one with a password in /etc/shadow.

By default, SSH server isn’t even installed. You would have to install the openssh-server package before anybody could SSH in.

After that, any user has to pass two checks:

SSH authentication means that either the user must have a valid password in /etc/shadow or they have a valid SSH public key with the right permissions in the target user’s ~/.ssh/authorized_keys .

Valid passwords are described further in the crypt(3) man page, but basically if the user’s 2nd field in /etc/shadow is anything starting with $NUMBER$ , it’s probably valid, and if it’s * or ! , it’s invalid.

PAM account checks basically means that the account is not expired. You can check that using chage -l USERNAME .

So to answer your questions, to my knowledge:

1. Only root and the account you create during the installation wizard can log in on a new system
2. No, because www-data has a hashed password of * and there is no ~www-data/.ssh/authorized_keys file
3. There’s no single list, because there are multiple requirements, but to get an idea, you could try running grep -v ‘^[^:]*:[!*]:’ /etc/shadow

Источник

Allowing only specific users to login via ssh at one port and others to login via another port

For added security, I was hoping to configure sshd to allow access to only particular users on port X (and then configure some alerts so that we can know when users are logging in through port X).

However, I am unable to find any configuration like this in sshd documentation. If there is no solution like this, is it at least possible to trigger a shell script to run whenever someone completes sshd login on port X? I was looking at iptables documentation to see if it could trigger an alert when sshd login is there but could not come up with anything.

3 Answers 3

Running SSH on an alternate port doesn’t count as security anymore. It only adds a slight bit of obscurity, and an added step of complexity for your users. It adds zero obstacles for people looking to break your network, who are using automated port scanners and don’t care what port it’s running on.

If you want to bolster security on a system that’s allowing remote internet-based inbound SSH, control your users in the sshd_config as @Anthon indicated, and then also implement security directly in PAM.

Create two groups, lusers and rusers . Add the remote mobile users to the rusers group. Use the pam_succeed_if.so PAM module to permit access to those users. Add lines to your pam config for ssh:

account sufficient pam_succeed_if.so user ingroup lusers account sufficient pam_succeed_if.so user ingroup rusers 

Some pam_succeed_if.so modules may require you to use slightly different syntax, like group = lusers .

Then, not only is sshd limiting the users that can connect, but in the event of a bug in sshd , you still have the protection that the PAM based restrictions offer.

One additional step for the remote users is to force the use of ssh_keys with passphrases. So, local users can login with keys or passwords, but remote users must have a key, and if you create the keys for them, you can make sure the key has a passphrase associates. Thus limiting access to locations that actually possess the SSH key and the passphrase. And limiting potential attack vectors if a user’s password is compomised.

ChallengeResponseAuthentication yes 

PasswordAuthentication yes 

ChallengeResponseAuthentication no 

PasswordAuthentication no 

So, the default is to now allow only key authentication. Then for local users you can user the match config setting to change the default for local users. Assuming your local private network is 192.168.1.0/24, add to sshd_config :

Match Address 192.168.1.0/24 PasswordAuthentication yes 

Now, the local users can connect with passwords or keys, and remote users will be forced to use keys. It’s up to you to create the keys with pass-phrases.

As an added benefit, you only have to manage a single sshd_config , and you only have to run ssh on a single port, which eases your own management.

edit 2017-01-21 — Limiting the use of authorized_keys files.

If you want to make sure that users cannot just self generate an ssh key, and use it with an authorized_keys file to login, you can control that by setting a specific location for sshd will look for authorized keys.

In /etc/ssh/sshd_config , change:

AuthorizedKeysFile %h/ssh/authorized_keys 

AuthorizedKeysFile /etc/.ssh/authorized_keys/%u 

Pointing to a controlled directory that users don’t have permissions to write to means they can’t generate their own key and use it to work around the rules you’ve put in place.

Источник

Allow/Deny Specific Users to Login via SSH on Ubuntu 18.04

Hello there, today we are going to learn how to allow/deny specific users to login via SSH on Ubuntu 18.04 system.

Allow/Deny Specific Users to Login via SSH on Ubuntu 18.04

Allow Specific Users to Login via SSH on Ubuntu 18.04

In order to allow specific users or a specific group of users to login to an Ubuntu 18.04 system via SSH, AllowUsers or AllowGroups options can be used in SSH daemon configuration file, /etc/ssh/sshd_config .

For example, to allow users, amos and admin to login, edit the SSHd configuration file and add the line below;

. AllowUsers amos admin

Once changes are made, restart SSH.

Now, if you try to login as any other user apart from the two allowed above, you should get permission denied.

ssh [email protected] [email protected]'s password: Permission denied, please try again.

If you check authentication logs, it states clearly;

Mar 27 19:46:07 u18svr sshd[886]: User mibey from 192.168.0.101 not allowed because not listed in AllowUsers

To allow a specific group of users to login, you would add the following line to SSHd configuration file;

AllowGroups administrators

This will allow only the members of the administrators group login

getent group administrators administrators:x:1004:admin,mibey

If you try to login as a user who is not a member of the administrators group, you will get permission denied.

ssh [email protected] [email protected]'s password: Permission denied, please try again

Deny Specific Users to Login via SSH on Ubuntu 18.04

Similarly, to deny a specific user from logging in via SSH, you simply use the DenyUsers or DenyGroups option with a list of users or groups to deny access respectively.

If you try to login as any of the above users, you will get permission denied.

To deny a group of users, say the administrator group whose members are admin and mibey, you would add the following line to SSHd configuration file.

DenyGroups administrators

Remember to reload SSH whenever you make any changes.

Great, that is all about how to allow/deny specific users to login via SSH on Ubuntu 18.04 system. Enjoy

SUPPORT US VIA A VIRTUAL CUP OF COFFEE

We’re passionate about sharing our knowledge and experiences with you through our blog. If you appreciate our efforts, consider buying us a virtual coffee. Your support keeps us motivated and enables us to continually improve, ensuring that we can provide you with the best content possible. Thank you for being a coffee-fueled champion of our work!

Источник

linux — enabling system user to login?

But now I want that user to be able to login. I can become that user using sudo , but also would like to directly log in using password. I tried using this command: sudo passwd user It lets me add password for user. When I try to login, it logins but instantly exits.

3 Answers 3

You can not log in as user because it is a system account, which is specified by the —system option. System accounts are for daemons or services, not for human users, and are therefore given /bin/false for login shell. If you enter grep ‘^user’ /etc/passwd , you will get something like this:

To allow user to log in, you can use usermod to change its login shell to bash:

Alternatively, you can also edit /etc/passwd by hand. You may also want to make some other changes to user ‘s UID, GID, and home directory location.

It might be that the user was created without the -m flag.

-r, --system Create a system account. System users will be created with no aging information in /etc/shadow, and their numeric identifiers are choosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in /etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the creation of groups). Note that useradd will not create a home directory for such an user, regardless of the default setting in /etc/login.defs (CREATE_HOME). You have to specify the -m options if you want a home directory for a system account to be created. -m, --create-home Create the user's home directory if it does not exist. The files and directories contained in the skeleton directory (which can be defined with the -k option) will be copied to the home directory. useradd will create the home directory unless CREATE_HOME in /etc/login.defs is set to no. 

Edit: Also, see this answer to another question.

Источник

How do you tell if a user is «allowed to log in» on Linux?

The question is simple, I want to list all the user accounts which can log in to my system, but I’m not sure if that all the users in /etc/passwd are «could login» users? Details: I can see users whose shells are set to /usr/sbin/nologin and /bin/false in /etc/passwd , does that mean they cannot login? I also know that I can set the encrypted password of user to * or ! in /etc/shadow to disable an account, so the «disabled user» should also be treat as «cannot log in» user, right?

3 Answers 3

A lot of this depends on your definition of «log in» — technically any user who exists in /etc/passwd & /etc/shadow is a «valid user» and could theoretically log in under the right set of circumstances.

The methods you’re talking about fall into the following broad categories:

• Users with «locked» accounts in /etc/shadow
  A user whose password is set to * , ! , or some other hash that will never match is «locked out» (in the Sun days the convention was often *LK* , for «Locked»).
  These users can’t log in by typing a password, but they can still log using other authentication mechanisms (SSH keys, for example).
• Users with a «non-interactive» shell in /etc/passwd
  A user whose account has a «non-interactive shell» ( /bin/false , /sbin/nologin ) can’t log in interactively — i.e. they can’t get a shell prompt to run commands at (this also prevents SSH command execution if the user has SSH keys on the system).
  These users may still be able to log in to do things like read/send email (via POP/IMAP & SMTP AUTH). Setting a non-interactive shell for users who should never need to use the shell (and for most «service accounts») is generally considered good practice.

So depending on your criteria for «able to log in» you may want to check one or both of these things.

Источник