# Problem with login.access



## Carolus Magnus (Nov 10, 2019)

Good afternoon,
I was playing around with login.access. I want to allow a specific machine on the network to be able to connect. The computer's name is cp9043 and the ip address is 192.168.1.15
It doesn't work when I use:

```
+:ALL:192.168.1.
+:wheel:console ttyv0
-:ALL:ALL
```
or:

```
+:ALL:192.168.1.15
+:wheel:console ttyv0
-:ALL:ALL
```
The result was always: 
	
	



```
sromanov is not allowed to log in from cp9043
```
It only works when I use:

```
+:ALL:cp9043
+:wheel:console ttyv0
-:ALL:ALL
```
Is there anyway I could use the ip address instead of the machine's name?


----------



## T-Daemon (Nov 11, 2019)

Try `+:ALL:192.168.1.15`


----------



## Carolus Magnus (Nov 11, 2019)

T-Daemon said:


> Try `+:ALL:192.168.1.15`


Oh, sorry, it was a typo. I already tried that.


----------



## SirDice (Nov 11, 2019)

Use the FQDN of the host, not the short name.


----------



## Carolus Magnus (Nov 11, 2019)

SirDice said:


> Use the FQDN of the host, not the short name.


Do you know why ip doesn't work? Since our IP doesn't change. But if our nameservers are compromised, FQDN can be directed to malicious hosts.


----------



## SirDice (Nov 11, 2019)

Carolus Magnus said:


> But if our nameservers are compromised, FQDN can be directed to malicious hosts.


An IP address would provide even less protection because anyone can put a system on your network using that IP.


----------



## gpw928 (Nov 11, 2019)

SirDice said:


> An IP address would provide even less protection because anyone can put a system on your network using that IP.


The man page for login.access() suggests that using an IP address should work:


> The third field should be a list of one or more tty names (for non-networked logins), host names, domain names (begin with "."), *host addresses*, internet network numbers (end with "."), ALL (always matches) or LOCAL (matches any string that does not contain a "." character).


A quick test indicates that IP addresses don't work.  This seems to me more like a bug than a security feature...


----------



## Carolus Magnus (Nov 12, 2019)

gpw928 said:


> The man page for login.access() suggests that using an IP address should work:
> 
> A quick test indicates that IP addresses don't work.  This seems to me more like a bug than a security feature...


Yes, indeed. It's really weird that a staff member simply avoids the question while the related code is redundant and have no comment at all (I tried to fix it but discovered that there's no comments).
I'm thinking that I bumped into something???


----------



## Carolus Magnus (Nov 12, 2019)

T-Daemon said:


> Try `+:ALL:192.168.1.15`


Could you try using ip for a quick test? Cause it seems that not only me have this issue.


----------



## SirDice (Nov 12, 2019)

Carolus Magnus said:


> It's really weird that a staff member simply avoids the question


I'm just a user like everyone else. I just happen to have a lot of experience and post a lot, which earned me a moderation status.


----------



## Carolus Magnus (Nov 12, 2019)

SirDice said:


> I'm just a user like everyone else. I just happen to have a lot of experience and post a lot, which earned me a moderation status.


Oh, sorry. Thought you were a developer of freebsd.


----------



## SirDice (Nov 12, 2019)

This is a _user_ support forum, there are very few developers here. They are typically only available through the various mailing lists.

There are a few developers here, you can easily identify them, their names have an @ symbol at the end.


----------



## T-Daemon (Nov 12, 2019)

Carolus Magnus said:


> Could you try using ip for a quick test? Cause it seems that not only me have this issue.


I can't reproduce the situation with my current setup: _FreeBSD-12.0 <--LAN--> Router <--WAN--> Android_.  `ssh user@FreeBSD-IP` from Android gives me access to every user (except root of course), with `+:ALL:192.168.1.`  or `+:ALL:192.168.1.15` (`.102`in my case) and `-:ALL:ALL` set.

What denies access with host addresses or internet network numbers set affects your and gpw928 's  setup.


----------



## T-Daemon (Nov 13, 2019)

Some progress in the troubleshooting. I could replicate the case. The host name cp9043 printed in


Carolus Magnus said:


> sromanov is not allowed to log in from cp9043


caught my attention. When setting invalid host addresses or internet network numbers in my testing I got an IP address printed in the deny message, not a host name. Setting IP  and alias `192.168.1.15 cp9043` in /etc/hosts reproduces exact the described behavior, with `+:ALL:192.168.1.15`and `+:ALL:192.168.1.` no access granted, but with  `+:ALL:cp9043` access granted.

I'm not sure where to investigate from here.


----------



## gpw928 (Nov 13, 2019)

I removed all entries from /etc/hosts, except for localhost, on the target system (ssh server).  

The resolvers on the target system are configured to resolve host names as follows:
	
	



```
[ritz.148] # grep ^hosts /etc/nsswitch.conf
hosts: files dns
```

The name server (dnsmasq) is running on my firewall, and resolves internal hosts names (dnsmasq is configured to get them from /etc/hosts on the firewall).

I then added the following to /etc/login.access on the target system
	
	



```
+:ALL:TESTADDR
+:wheel:console ttyv0
-:ALL:ALL
```

Login to the target system with ssh worked with  TESTADDR set to the FQDN of the ssh client.  It failed when set to the unadorned host name of the ssh client, or the network of the ssh client "192.168.1.", or the IP address of the ssh client "192.168.1.26".

The failure was always at the same place:
	
	



```
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/phil/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 1047
debug2: input_userauth_pk_ok: fp SHA256:7HF7sXN4bNIBeX9MbTvajh4Iu+IF4FHTh1uZwhmQUQQ
debug3: sign_and_send_pubkey: RSA SHA256:7HF7sXN4bNIBeX9MbTvajh4Iu+IF4FHTh1uZwhmQUQQ
debug3: send packet: type 50
debug3: receive packet: type 53
debug3: input_userauth_banner
phil is not allowed to log in from <FDQN of ssh client>
Authentication failed.
```
This smells like a bug to me.


----------



## T-Daemon (Nov 13, 2019)

Update on case, I created a few new users, every new user is able to login, whereas the pre /etc/login.access settings created users aren't able to (except one, I couldn't determine what is different compaired to the others). Carolus Magnus, gpw928 can you verify?

/etc/hosts

```
192.168.1.15  <host alias>
```

/etc/login.access

```
+:ALL:192.168.1.  #(or 192.168.1.15)
+:wheel:console ttyv0
-:ALL:ALL
```

Looks like a bug indeed.


----------



## gpw928 (Nov 14, 2019)

I have added a new user, and the test results are the same as I posted above (IP addresses and network numbers don't work).

I should have mentioned that the test system is running FreeBSD 11.3-RELEASE.


----------



## Carolus Magnus (Nov 15, 2019)

I added a new user, same result.
The test system is running FreeBSD 12.9 RELEASE


----------



## Carolus Magnus (Nov 15, 2019)

gpw928 said:


> I have added a new user, and the test results are the same as I posted above (IP addresses and network numbers don't work).
> 
> I should have mentioned that the test system is running FreeBSD 11.3-RELEASE.


Check out bug 94051 in their freebsd bug report system https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=94051
It's been unfixed for 13 years.


----------



## gpw928 (Nov 15, 2019)

It's only been there since 7.0 CURRENT...   A DoS attack on the DNS server while you login should provide a work around until such time it's fixed...


----------



## Carolus Magnus (Nov 15, 2019)

gpw928 said:


> It's only been there since 7.0 CURRENT...   A DoS attack on the DNS server while you login should provide a work around until such time it's fixed...


Emm, I will just go into the source code, fix it and compile everything on my own.


----------

