# Restrict login access through login.access



## usakhncit (Dec 26, 2020)

Hi
I have a user named "john" in my FreeBSD machine, who is not a member of wheel group. For learning purpose, I am trying to restrict this user from login to the system. So, I put following in the file (/etc/login.access)

```
-:ALL EXCEPT wheel:LOCAL
```
However, john can still login to the system. Am I making any mistake here?
Thanks


----------



## chrbr (Dec 26, 2020)

As far as I know you can assign a shell as /usr/sbin/nologin. In /etc/passwd should be some examples already. There are also nologin(8) with some information.


----------



## usakhncit (Dec 26, 2020)

chrbr said:


> As far as I know you can assign a shell as /usr/sbin/nologin. In /etc/passwd should be some examples already. There are also nologin(8) with some information.


That's one way to do it.
Actually, I am reading (and practicing) Absolute FreeBSD by Michael W. Lucas. At page 195 (Chapter 7), he is talking about "Restricting Login Ability" through (/etc/login.access). However, when I try to apply it on my system, it does not work. So, there may be some reason that why it is not working on my system. Is it obsolete? Or any relevant service is required to be enabled? Or am I making any mistake here?


----------



## T-Daemon (Dec 26, 2020)

zetrotrack000 said:


> -:ALL EXCEPT wheel:LOCAL


Set `-:ALL EXCEPT wheel:ALL`


----------



## usakhncit (Dec 26, 2020)

T-Daemon said:


> Set `-:ALL EXCEPT wheel:ALL`


Nope, it's not working. John is still able to login.


----------



## T-Daemon (Dec 27, 2020)

zetrotrack000 said:


> Nope, it's not working. John is still able to login.


This might be a case of regression. I ran a series of tests, it seems that on 12.2-RELEASE (I don't know about STABLE or CURRENT) the login access control table, /etc/login.access, is ignored.

How to reproduce:

On 12.1-RELEASE:

```
# adduser (name john, don't invite into other groups)

Edit /etc/login.access

-:ALL EXCEPT wheel:ALL
Or
-:john:ALL
```
"john" is denied login.

On 12.2-RELEASE:

Same setup as above, "john" can log in, even when `-:ALL:ALL` is set. This should deny login even for "root".

Who is filing the bug report?


----------



## usakhncit (Dec 27, 2020)

T-Daemon said:


> This might be a case of regression. I ran a series of tests, it seems that on 12.2-RELEASE (I don't know about STABLE or CURRENT) the login access control table, /etc/login.access, is ignored.
> 
> How to reproduce:
> 
> ...


I have filed the bug which can be tracked at PR 252194.


----------



## chrbr (Dec 27, 2020)

I have filed PR 252195.
Ups, I have been late but I cannot see your pr. I keep mine active.

EDIT:
The message is You are not authorized to access bug #252194. To see this bug, you must first log in to an account with the appropriate permissions.
An erroris displayed even when I log in. May be things have to settle at bugzilla first.


----------



## usakhncit (Dec 27, 2020)

chrbr said:


> The message is You are not authorized to access bug #252194. To see this bug, you must first log in to an account with the appropriate permissions.
> An erroris displayed even when I log in. May be things have to settle at bugzilla first.


Is this due to restrictions by the website (bugzilla)? Or do I have to make any change in my account's preferences?
EDIT:
Maybe it is due to Assignee. Am I right?


----------



## chrbr (Dec 27, 2020)

zetrotrack000 said:


> Maybe it is due to Assignee. Am I right?


Thi can be. I my pr the bug is assigned to freebsd-bugs (Nobody). But I did not change anything to have that assignment.
When I can see your pr I will mark mine as a duplicate because you have been faster than me .


----------



## usakhncit (Dec 27, 2020)

chrbr said:


> ...because you have been faster than me .


...because I had plenty of free time today  .


----------



## Rob215x (Aug 11, 2021)

usakhncit said:


> Actually, I am reading (and practicing) Absolute FreeBSD by Michael W. Lucas. At page 195 (Chapter 7), he is talking about "Restricting Login Ability" through (/etc/login.access). However, when I try to apply it on my system, it does not work.


I just wanted to chime in here and say I've been reading the same book. I think it's a pretty good book but the /etc/login.access isn't working on my system either. It simply doesn't seem to have any effect. I'm running FreeBSD 11.4.

Here's my code (in the actual file xx.xx.xx.xx is my home office IP, I'm just hiding it here)

```
+:wheel:console
+:wheel:192.168.0. xx.xx.xx.xx
-:ALL:ALL
```

I also tried the single line, ALL EXCEPT method, using examples from the book.

I could still log in from another IP address.

In sshd_config I already have: PermitRootLogin no so all logins must be from users in the wheel group.

I simply want to deny all logins from everywhere except a few IPs and our office network.


----------



## mark_j (Aug 11, 2021)

PR 252195 was fixed this February, so if you're running 11.4 you need to update to P8.

Besides this, you seem to be going about it wrong. If you only want some IPs to connect, enable a firewall and block everything but those IPs.


----------



## Rob215x (Aug 11, 2021)

mark_j said:


> PR 252195 was fixed this February, so if you're running 11.4 you need to update to P8.
> 
> Besides this, you seem to be going about it wrong. If you only want some IPs to connect, enable a firewall and block everything but those IPs.


Thanks for your reply. I do all updates on a regular basis. I'm going to be from 11 to 12.x in the next couple of weeks though so that should take care of it I guess? 

I agree the firewall approach is probably best but login.access *should* work right?


----------



## mark_j (Aug 11, 2021)

So you're at P8? In that case it should be working. 

It's likely if it still has issues with 11.4R P8 then it will with 12.2 r369359 or later as they were both patched in Feb 2020.

File a new PR perhaps?


----------



## Rob215x (Aug 11, 2021)

mark_j said:


> So you're at P8? In that case it should be working.
> 
> It's likely if it still has issues with 11.4R P8 then it will with 12.2 r369359 or later as they were both patched in Feb 2020.
> 
> File a new PR perhaps?


It turns out, this box wasn't up to date as far as patches. 

As soon as I applied the latest patches (P12) it worked. But now I have a new problem and I'm going to create a separate post for that.


----------

