In my home network I have 1 server and several other boxes, with port 22 forwarded by my router to the server. I have one user with a long and uncommon user name and very long password, which I use only to ssh in from outside my network. I restrict ssh from outside to this user, but allow from other users from within my network.

For illustration purposes, let's say I use 192.168.0.* for my network, with the server called blue and a workstation called green.

I have used in the past an sshd_config file like this:

DenyUsers `*'
AllowUsers longuser'sname
AllowUsers otheruser@192.168.0.*

Recently I upgraded my server to Fedora Core 3 (from FC1). Initially, things worked the same as before. Then I added names and ips for the other hosts on my network to /etc/hosts (as I had done with the FC1 server). Now I get login denied for users on the 192... network. The ssh log file confirms that it's due to the DenyUsers setting.

However, if I make an entry like this: AllowUsers otheruser@green, then that user can log in from green to blue (the server box). I can work with this, but I'm curious as to why specification by ip is not working. I also wonder if someone could fool ssh with hostname spoofing.

As it is, I have a pretty good workaround, but I'd be very interested if anyone has an idea why AllowUsers won't still work by ip. My ssh reports this info: OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003, with a 2.6.x kernel. Again the /etc/hosts is what worked before with the FC1 install.

Got no idea. Maybe start by running sshd in debugmode (triple "-d" argument) and post the log.

I usually use the init script or just the RH service command for starting sshd. Server is headless, so tried via crontab script to kill sshd and restart via /usr/sbin/sshd -d -d -d, logging output to a file.

Didn't work and I got:
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.

Meaning, I suppose, that it wants an ip address passed also or it defaults to none? Although a quick reading of the man page doesn't seem to indicate this.

A quick read of the man page of sshd_config also doesn't seem to indicate an easy way to specify debug with the config file.

Maybe if I get some time tomorrow I'll figure out how to log verbosely. It's getting a bit late tonight.

Server is headless, so tried via crontab script to kill sshd and restart via /usr/sbin/sshd -d -d -d, logging output to a file.
If headless you'll want another (chance at) instance running before you find you can't log in again :-]
Either tru Xinetd or a sep instance on a high port and make sure login, host and network access listings don't stop you...

Didn't work and I got:
debug1: Bind to port 22 on 0.0.0.0.
Bind to port 22 on 0.0.0.0 failed: Address already in use.
Meaning, I suppose, that it wants an ip address passed also or it defaults to none? Although a quick reading of the man page doesn't seem to indicate this.
No, means there still where instances of something running on that port.
Spose you didn't kill all of 'em.
AFAIK default sshd behaviour is to bind to all interfaces except loopback.

A quick read of the man page of sshd_config also doesn't seem to indicate an easy way to specify debug with the config file.
No, you could use the options in /etc/sysconfig/sshd, but beware this will be used for all instances of starting up ssd AND a sshd in debug mode is killed right after user logout, so that's no use if you don't run a service restarter like Monit!

I think that the "port already in use" is because I already connected once to the sshd in debug mode. Seems to start once, then, after one client connection, dies. If the client connection succeeded, the sshd in debug mode lives until the client logs out.

Anyway, lots of output, some of which I'll reproduce below.

Started like this:

/usr/sbin/sshd -p 8022 -d -d -d

Lots of output to the session, none regarding reasons for connections accepted or denied.

Now a fair sampling from /var/log/secure(replacing real user name with "someuser" and real host names):

Nov 28 22:43:10 blue sshd[3395]: debug1: inetd sockets after dupping: 3, 3
Nov 28 22:43:10 blue sshd[3395]: Connection from ::ffff:192.168.0.102 port 41171
Nov 28 22:43:10 blue sshd[3395]: debug1: Client protocol version 2.0; client software version OpenSSH_3.9p1
Nov 28 22:43:10 blue sshd[3395]: debug1: match: OpenSSH_3.9p1 pat OpenSSH*
Nov 28 22:43:10 blue sshd[3395]: debug1: Enabling compatibility mode for protocol 2.0
Nov 28 22:43:10 blue sshd[3395]: debug1: Local version string SSH-1.99-OpenSSH_3.9p1
Nov 28 22:43:10 blue sshd[3395]: debug2: fd 3 setting O_NONBLOCK
Nov 28 22:43:10 blue sshd[3395]: debug2: Network child is on pid 3396
Nov 28 22:43:10 blue sshd[3395]: debug3: preauth child monitor started
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:10 blue sshd[3395]: debug3: monitor_read: checking request 0
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_moduli: got parameters: 1024 1024 8192
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_send entering: type 1
Nov 28 22:43:10 blue sshd[3395]: debug2: monitor_read: 0 used once, disabling now
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:10 blue sshd[3395]: debug3: monitor_read: checking request 5
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_sign
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_sign: signature 0x8168900(143)
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_send entering: type 6
Nov 28 22:43:10 blue sshd[3395]: debug2: monitor_read: 5 used once, disabling now
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:10 blue sshd[3395]: debug3: monitor_read: checking request 7
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_pwnamallow
Nov 28 22:43:10 blue sshd[3395]: debug3: Normalising mapped IPv4 in IPv6 address
Nov 28 22:43:10 blue sshd[3395]: debug3: Trying to reverse map address 192.168.0.102.
Nov 28 22:43:10 blue sshd[3395]: User someuser not allowed because not listed in AllowUsers
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 0
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_send entering: type 8
Nov 28 22:43:10 blue sshd[3395]: debug2: monitor_read: 7 used once, disabling now
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:10 blue sshd[3395]: debug3: monitor_read: checking request 46
Nov 28 22:43:10 blue sshd[3395]: debug1: PAM: initializing for "someuser"
Nov 28 22:43:10 blue sshd[3395]: debug1: PAM: setting PAM_RHOST to "green"
Nov 28 22:43:10 blue sshd[3395]: debug1: PAM: setting PAM_TTY to "ssh"
Nov 28 22:43:10 blue sshd[3395]: debug2: monitor_read: 46 used once, disabling now
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:10 blue sshd[3395]: debug3: monitor_read: checking request 3
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_authserv: service=ssh-connection, style=
Nov 28 22:43:10 blue sshd[3395]: debug2: monitor_read: 3 used once, disabling now
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:10 blue sshd[3395]: debug3: monitor_read: checking request 4
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_answer_authrole: role=
Nov 28 22:43:10 blue sshd[3395]: debug2: monitor_read: 4 used once, disabling now
Nov 28 22:43:10 blue sshd[3395]: debug3: mm_request_receive entering
Nov 28 22:43:12 blue sshd[3395]: debug3: monitor_read: checking request 11
Nov 28 22:43:12 blue sshd[3395]: debug3: PAM: sshpam_passwd_conv called with 1 messages
Nov 28 22:43:14 blue sshd[3395]: debug1: PAM: password authentication failed for an illegal user: Authentication failure
Nov 28 22:43:14 blue sshd[3395]: debug3: mm_answer_authpassword: sending result 0
Nov 28 22:43:14 blue sshd[3395]: debug3: mm_request_send entering: type 12
Nov 28 22:43:14 blue sshd[3395]: Failed password for invalid user someuser from ::ffff:192.168.0.102 port 41171 ssh2

The relevant line seems to be "User someuser not allowed because not listed in AllowUsers", which doesn't shed much light on the original question.

Maybe I ought to post to either a Fedora list or Openssh list where maybe a developer might know if there has been a change in behavior.