Problem with login.access

Carolus Magnus

New Member


Messages: 9

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:
Code:
+:ALL:192.168.1.
+:wheel:console ttyv0
-:ALL:ALL
or:
Code:
+:ALL:192.168.1.15
+:wheel:console ttyv0
-:ALL:ALL
The result was always:
Code:
sromanov is not allowed to log in from cp9043
It only works when I use:
Code:
+:ALL:cp9043
+:wheel:console ttyv0
-:ALL:ALL
Is there anyway I could use the ip address instead of the machine's name?
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,300
Messages: 38,823

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

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,300
Messages: 38,823

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

Aspiring Daemon

Reaction score: 241
Messages: 555

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...
 
OP
C

Carolus Magnus

New Member


Messages: 9

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???
 

SirDice

Administrator
Staff member
Administrator
Moderator

Reaction score: 12,300
Messages: 38,823

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

Daemon

Reaction score: 876
Messages: 1,750

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

Daemon

Reaction score: 876
Messages: 1,750

Some progress in the troubleshooting. I could replicate the case. The host name cp9043 printed in
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

Aspiring Daemon

Reaction score: 241
Messages: 555

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:
Code:
[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
Code:
+: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:
Code:
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

Daemon

Reaction score: 876
Messages: 1,750

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
Code:
192.168.1.15  <host alias>

/etc/login.access
Code:
+:ALL:192.168.1.  #(or 192.168.1.15)
+:wheel:console ttyv0
-:ALL:ALL

Looks like a bug indeed.
 

gpw928

Aspiring Daemon

Reaction score: 241
Messages: 555

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.
 

gpw928

Aspiring Daemon

Reaction score: 241
Messages: 555

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... ;)
 
OP
C

Carolus Magnus

New Member


Messages: 9

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.😇
 
Top