Are /etc/hosts.allow and /etc/hosts.deny being used for access control
on the cluster? Perhaps the new MacBook ip is not permitted? Logs on
the cluster probably explain the failure, since that side is closing the
connection.
-Ed
Pann McCuaig wrote:
So here's the deal. One of my users just bought a small MacBook to keep
her MacBook Pro company. Both are running fully updated Leopard.
She can log into our computing cluster login node, which is running
SL4.7, just fine with her MacBook Pro. When she attempts to log into the
same host with her MacBook, she gets this:
bash-3.2$ ssh -vv cluster.econ.columbia.edu
OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to cluster.econ.columbia.edu [128.59.160.209] port 22.
debug1: Connection established.
debug1: identity file /Users/(masked)/.ssh/identity type -1
debug1: identity file /Users/(masked)/.ssh/id_rsa type -1
debug1: identity file /Users/(masked)/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
bash-3.2$
No password is requested, although that should be the fallback
authentication method.
/etc/ssh_config on both her Macs are box stock: all the defaults are
listed as comments.
HOWEVER, not only can she log into assorted non-SL unix and linux
systems with her new MacBook, she can log into a host running SL5.3.
/etc/sshd_config on both the SL4.7 and SL5.3 box are just as they come
from the rpm, except for:
PermitRootLogin no
SL4.7
-----
openssh-3.9p1-11.el4_7.x86_64
openssh-askpass-3.9p1-11.el4_7.x86_64
openssh-askpass-gnome-3.9p1-11.el4_7.x86_64
openssh-clients-3.9p1-11.el4_7.x86_64
openssh-server-3.9p1-11.el4_7.x86_64
SL5.3
-----
openssh-4.3p2-29.el5.x86_64
openssh-askpass-4.3p2-29.el5.x86_64
openssh-clients-4.3p2-29.el5.x86_64
openssh-server-4.3p2-29.el5.x86_64
Anyone have ANY IDEA what's going on?
Cheers,
Pann
