Ssh fails with rule matching LAN

Question

My goal is simple: use a key pair from the WAN only but allow password auth from the LAN.
I thought my recipe had previously worked in Arch and other distros, but now I'm unsure. Here's a snippet of some relevant sections of /etc/ssh/sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
Match Address 192.168.1.0/24
PasswordAuthentication yes
Without the match section I'm able to login. With the match section I am not able to login from WAN or LAN hosts.
Here's an excerpt from the ssh client logging in from the localmachine itself along with a tail of the journal (using the match address section):
CLIENT SIDE
myhost% ssh -v localhost
OpenSSH_6.4, OpenSSL 1.0.1f 6 Jan 2014
debug1: Reading configuration data /home/myuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /home/myuser/.ssh/id_rsa type 1
debug1: identity file /home/myuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_dsa type -1
debug1: identity file /home/myuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/myuser/.ssh/id_ecdsa type 3
debug1: identity file /home/myuser/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4
debug1: match: OpenSSH_6.4 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr [email protected] none
debug1: kex: client->server aes128-ctr [email protected] none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA <ommited pub>
debug1: Host 'localhost' is known and matches the ECDSA host key.
debug1: Found key in /home/myuser/.ssh/known_hosts:6
debug1: ssh_ecdsa_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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/myuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/myuser/.ssh/id_dsa
debug1: Offering ECDSA public key: /home/myuser/.ssh/id_ecdsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
SERVER SIDE
myhost% sudo journalctl -f --full
-- Logs begin at Sat 2013-06-29 11:25:32 EDT. --
Jan 07 13:09:18 myhost systemd[1]: Started SSH Key Generation.
Jan 07 13:09:18 myhost systemd[1]: Starting OpenSSH Daemon...
Jan 07 13:09:18 myhost systemd[1]: Started OpenSSH Daemon.
Jan 07 13:09:18 myhost sudo[20291]: pam_unix(sudo:session): session closed for user root
Jan 07 13:09:18 myhost sshd[20295]: Server listening on 0.0.0.0 port 22.
Jan 07 13:09:18 myhost sshd[20295]: Server listening on :: port 22.
Jan 07 13:09:23 myhost sshd[20296]: reverse mapping checking getaddrinfo for <omitted address> [<omitted address>] failed - POSSIBLE BREAK-IN ATTEMPT!
Jan 07 13:09:34 myhost sshd[20296]: error: Received disconnect from <omitted address>: 13: Unable to authenticate [preauth]
Jan 07 13:09:39 myhost sudo[20298]: myuser : TTY=pts/2 ; PWD=/home/myuser ; USER=root ; COMMAND=/usr/bin/journalctl -f --full
Jan 07 13:09:39 myhost sudo[20298]: pam_unix(sudo:session): session opened for user root by myuser(uid=0)
Jan 07 13:10:35 myhost sshd[20308]: Connection closed by ::1 [preauth]
Last edited by badhat (2014-01-08 14:36:10)

Answer 1

Yes, there are one or two fields which were note mapped and were removed. However, the records which got reconciled successfully have been done with the same field mapping.
UZ