NIS+PAM+SSH+Firewalling.....all in the mix

I've encountered an issue in trying to setup an iptables firewall
(shorewall) on a debian etch server (hostname zeus). Zeus is a NIS
client retrieving account info from a NIS server somewhere in our
infrastructure.

I setup a preliminary/testing list of firewall rules which doesn't
include any rules for NIS, with the default rule for the NIS server<-
>zeus conversation to DROP. I've included an ssh rule which allows
everyone to ssh to zeus. The 1st twist is that I have disabled user
logins on zeus, via PAM, and only root can ssh to that machine. The
2nd twist is that the root account is local to zeus i.e. there's no
root account in the NIS database, so all ssh root@zeus authenticate
locally.

So far, so good. My firewall rules should allow something like
ssh root@zeus
since the authentication is done locally and no NIS operations are
required for root to be granted access.

A final thing is that I ssh to zeus using pubkey authentication.

The thing is that this setup doesn't work. The ssh -vvv command shows
that the client I ssh from, sends the pubkey and then sits there
waiting for zeus to reply. No reply...

After a few hours I suspected that NIS has something to do with this
problem. I stop the NIS client on zeus and, voila, the whole thing
works like a charm, I ssh with no problems.

I start ypbind on zeus again. In order to verify that NIS is indeed
the source of my problems, I tcpdump the conversation between zeus and
the NIS server and it seems that whenever I ssh to root@zeus from a
client, NIS kicks in and zeus query the NIS server. Since there is no
firewall rule which allows NIS to take place between zeus and the
NIS server, ssh fails.

Remember I use pubkey authentication.

I have several questions regarding this problem.
a) Is there a way to instruct ssh mechanism to try pubkey
authentication 1st and IF that fails to try password authentication?
b) Suppose I don't use pubkey authentication. Since the root@zeus
account is local how can I instruct PAM to check only /etc/passwd and
NOT NIS?
c) A more generall question. How does PAM interact with /etc/
nsswitch.conf - zeus's nsswitch.conf uses the compat option for
passwd, groups and shadow entries and /etc/passwd has a +:::::: at the
end.
d) Another option would be to include a firewall rule which would
allow zeus to talk to the NIS server. A while different discussion I
suspect since ypbind on debian etch doesn't allow you to bind a
specific port (-p option) to it. RPC nightmare..... So I wouldn't want
to go down that track. Plus I'd really like to know why this NIS @#!@#
takes place, when I ssh using pubkey (ie no password checking) on a
local (non NIS) account.

thx for reading my huge post.
vassilis

billis wrote:
> I've encountered an issue in trying to setup an iptables firewall
> (shorewall) on a debian etch server (hostname zeus). Zeus is a NIS
> client retrieving account info from a NIS server somewhere in our
> infrastructure.
>
> I setup a preliminary/testing list of firewall rules which doesn't
> include any rules for NIS, with the default rule for the NIS server<-
>> zeus conversation to DROP. I've included an ssh rule which allows
> everyone to ssh to zeus. The 1st twist is that I have disabled user
> logins on zeus, via PAM, and only root can ssh to that machine. The
> 2nd twist is that the root account is local to zeus i.e. there's no
> root account in the NIS database, so all ssh root@zeus authenticate
> locally.
>
> So far, so good. My firewall rules should allow something like
> ssh root@zeus
> since the authentication is done locally and no NIS operations are
> required for root to be granted access.
>
> A final thing is that I ssh to zeus using pubkey authentication.
>
> The thing is that this setup doesn't work. The ssh -vvv command shows
> that the client I ssh from, sends the pubkey and then sits there
> waiting for zeus to reply. No reply...
>
> After a few hours I suspected that NIS has something to do with this
> problem. I stop the NIS client on zeus and, voila, the whole thing
> works like a charm, I ssh with no problems.
>
> I start ypbind on zeus again. In order to verify that NIS is indeed
> the source of my problems, I tcpdump the conversation between zeus and
> the NIS server and it seems that whenever I ssh to root@zeus from a
> client, NIS kicks in and zeus query the NIS server. Since there is no
> firewall rule which allows NIS to take place between zeus and the
> NIS server, ssh fails.
>
> Remember I use pubkey authentication.
>
> I have several questions regarding this problem.
> a) Is there a way to instruct ssh mechanism to try pubkey
> authentication 1st and IF that fails to try password authentication?
> b) Suppose I don't use pubkey authentication. Since the root@zeus
> account is local how can I instruct PAM to check only /etc/passwd and
> NOT NIS?
> c) A more generall question. How does PAM interact with /etc/
> nsswitch.conf - zeus's nsswitch.conf uses the compat option for
> passwd, groups and shadow entries and /etc/passwd has a +:::::: at the
> end.
> d) Another option would be to include a firewall rule which would
> allow zeus to talk to the NIS server. A while different discussion I
> suspect since ypbind on debian etch doesn't allow you to bind a
> specific port (-p option) to it. RPC nightmare..... So I wouldn't want
> to go down that track. Plus I'd really like to know why this NIS @#!@#
> takes place, when I ssh using pubkey (ie no password checking) on a
> local (non NIS) account.

NIS is used for more than just authentication. If permissions are
checked, then NIS will get used.

Try disabling SSH's PAM (UsePAM no) via sshd_config and restart
your SSH daemon. See if that still causes a problem. If not,
then certainly some check inside of the pam stack is to blame.