Linux user no login allowed

Can’t allow users to log in via SSH (Bash, OpenSSH, CentOS 6.5)

Why is SSH not allowing login while the AllowUsers list obviously lists muser? Is there another place where this could be set?

UPDATE: I attempted a login to that account on my machine after adding my pub key to the user’s authorized_keys file with the verbose flag -v . These are the results (with a fake IP and server host key for security reasons):

$ ssh -v mattm@111.111.111.111 OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014 debug1: Reading configuration data /c/Users/[user]/.ssh/config debug1: Connecting to 111.111.111.111 [111.111.111.111] port 22. debug1: Connection established. debug1: identity file /c/Users/[user]/.ssh/id_rsa type 1 debug1: identity file /c/Users/[user]/.ssh/id_rsa-cert type -1 debug1: identity file /c/Users/[user]/.ssh/id_dsa type -1 debug1: identity file /c/Users/[user]/.ssh/id_dsa-cert type -1 debug1: identity file /c/Users/[user]/.ssh/id_ecdsa type -1 debug1: identity file /c/Users/[user]/.ssh/id_ecdsa-cert type -1 debug1: identity file /c/Users/[user]/.ssh/id_ed25519 type -1 debug1: identity file /c/Users/[user]/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA [censored] debug1: Host '111.111.111.111' is known and matches the RSA host key. debug1: Found key in /c/Users/[user]/.ssh/known_hosts:4 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Next authentication method: publickey debug1: Offering RSA public key: /c/Users/[user]/.ssh/id_rsa debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /c/Users/[user]/.ssh/id_dsa debug1: Trying private key: /c/Users/[user]/.ssh/id_ecdsa debug1: Trying private key: /c/Users/[user]/.ssh/id_ed25519 debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). 

Источник

Как создать пользователя Linux, который не может войти в систему

По соображениям безопасности вам может потребоваться создать пользователя Linux без возможности входа. Джек Валлен покажет вам, как это сделать.

У системных администраторов Linux, бывают случаи, когда вам может понадобиться создать пользователя, который не имеет возможности войти в систему. Когда этот тип пользователя будет необходим? Скажем, например, вы должны создать пользователя для правильной работы приложения, но вы не хотите, чтобы у этого пользователя был домашний каталог или возможность входа в систему.

Безопасность. Чем больше пользователей в вашей системе Linux, тем больше шансов, что злоумышленники могут взломать ее и нанести ущерб. Это особенно верно, когда мы говорим о пользовательской учетной записи, которая не будет использоваться реальным человеком, поэтому она не будет отслеживаться никоим образом.

Есть несколько способов справиться с этой задачей, но я хочу показать вам правильный способ сделать это.

Что вам нужно

1. Работающий экземпляр любого дистрибутива Linux
2. Учетная запись пользователя с привилегиями sudo

Как создать учетную запись Linux

Помните, мы создаем учетную запись Linux, которая не может войти в систему. Другими словами, это системная учетная запись. Допустим, учетная запись, которую вы хотите создать, называется nouser . Есть два правильных способа создания этой системной учетной записи.

Первый способ требует, чтобы вы вручную сконфигурировали оболочку, чтобы пользователь не мог войти в систему. Войдите на свой сервер Linux или на рабочий стол и введите команду:

sudo adduser nouser --shell=/bin/false 

Это установит оболочку в /bin/false , поэтому пользователь nouser не сможет войти в систему. Вам будет предложено ввести и подтвердить пароль, а затем заполнить информацию для пользователя:

Следующий метод использует параметр --system следующим образом:

sudo adduser nouser --system 

Приведенный выше метод создает учетную запись без пароля и без оболочки, поэтому он не может войти в систему. Тем не менее, вышеуказанный метод также создает домашний каталог. Если вы не хотите, чтобы домашний каталог создавался, команда будет выглядеть так:

sudo adduser nouser --system --no-create-home 

Если вам абсолютно не нужен домашний каталог для учетной записи, абсолютный самый безопасный метод - последний метод. Почему? Потому что нет пароля для учетной записи, а также нет домашнего каталога.

Как добавить пользователя в группу

Часто системные учетные записи относятся к группам. Скажем, этот пользователь должен входить в группу www-data. Для этого сначала нужно создать пользователя с помощью команды adduser , а затем добавить его в группу www-data с помощью команды:

sudo usermod -aG www-data nouser 

Теперь у вас есть системная учетная запись, которая не может войти в систему, которая входит в группу www-data.

Поздравляем, теперь вы знаете, как создавать пользователей системы Linux, которые не могут войти в систему и не имеют домашнего каталога - используйте этих пользователей с умом.

Источник

How can I su to a user with no login shell?

In Debian 10 I want to create a user who cannot log in directly. One should only be able to access the user by using the su binary. In my Ubuntu 18.04 setup, I did exactly this and it worked like charm, but in Debian 10 I am not able to do so.

Hint

What I've done

I've setup a user with the default shell /usr/sbin/nologin . But when trying to access this user by su --shell=/bin/bash user I am not able to do so.

Minimal example

# useradd --shell /usr/sbin/nologin locked # passwd locked Enter new UNIX password: *secret* Retype new UNIX password: *secret* passwd: password updated successfully $ su --shell /bin/bash locked Password: *secret* This account is currently not available. 

Edit 1:

$ cat /etc/shells # /etc/shells: valid login shells /bin/sh /bin/dash /bin/bash /bin/rbash /bin/zsh /usr/bin/zsh 

Edit 2:

A little more detailed answer on what I want to achieve: I am trying to create a user (user1) that is able to login to the computer either by SSH or by using a monitor and a keyboard. This user1 user should have restricted rights. One of this restrictions is, that he is not able to use sudo application, he is simply not allowed to do so. Then I have a second user (user2) which will be able to use the sudo application to perform some configuration tasks, like changing network settings or some other things. This user2 should be locked to log into by default. So no login by SSH and (more belonging to my problem) no login by monitor and keyboard. --> When someone wants to perform some task he has to login as the restricted user1, change the user to user2 and then he is allowed to change some configuration or something like that. This is all in all the situation I want to achieve. There are some, more fine grained details what the users are allowed or not allowed to do. But to describe it as simple as possible I simply explained it with `sudo.

Источник

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.

Источник