This new xinetd-2.1.8.9pre11-1 looks to me in an absence of a name server on a subnetwork quite thoroughly broken. My test machine is now 'kinga.home.front' and in /etc/hosts has, among other things a line 192.168.23.4 thebox.home.front thebox in /etc/hosts.allow one can find things like that: ALL: 127.0.0.1, \ LOCAL, \ 192.168.23. : \ allow and in /etc/nsswitch.conf hosts: files nisplus nis dns Despite of all this trying on 'thebox' the following $ ssh -v -l michal kinga results in this: thebox.home.front: Connecting to kinga [192.168.23.6] port 22. thebox.home.front: Allocated local port 1022. thebox.home.front: connect: Connection refused thebox.home.front: Trying again... thebox.home.front: Connecting to kinga [192.168.23.6] port 22. thebox.home.front: Allocated local port 1022. thebox.home.front: connect: Connection refused thebox.home.front: Trying again... thebox.home.front: Connecting to kinga [192.168.23.6] port 22. thebox.home.front: Allocated local port 1022. thebox.home.front: connect: Connection refused thebox.home.front: Trying again... thebox.home.front: Connecting to kinga [192.168.23.6] port 22. thebox.home.front: Allocated local port 1022. thebox.home.front: connect: Connection refused Secure connection to kinga refused; reverting to insecure method. Using rsh. WARNING: Connection will not be encrypted. /usr/bin/rsh kinga -l michal and on 'kinga' I get in /var/log/messages this: Oct 18 14:24:26 kinga xinetd[7283]: warning: /etc/hosts.allow, line 18: can't verify hostname: gethostbyname(thebox.home.front) failed Oct 18 14:24:26 kinga pam_rhosts_auth[7859]: denied to michal.front as michal: access not allowed Oct 18 14:24:26 kinga PAM_unix[7860]: (system-auth) session opened for user michal by (uid=0) Nothing of that sort happens when trying to connect on the same network to x86 machine with RH 7 but which still is using xinetd-2.1.8.9pre9-6. Doing 'ssh -v' from 'thebox' produces thebox.home.front: Allocated local port 1020. thebox.home.front: Connection established. To add insult to injury 'tcpdcheck' and 'tcpdmatch' were dumped instead of fixing a parser to read xinetd.conf as well. Michal michal
ssh doesn't use xinetd?
The sshd server doesn't use xinetd, but it does use tcp-wrappers internally. Kinga doesn't appear to be listening on port 22... is it actually running sshd? Does shutting sshd down using the init script, running "sshd -d" on kinga, and attempting to connect from thebox using ssh give any other information?
Oops. Scratch that report. I am an idiot! I failed to notice that an upgrade from an existing 6.2 installation dropped in on my disk openssh-askpass-2.1.1p4-1 openssh-2.1.1p4-1 openssh-clients-2.1.1p4-1 openssh-askpass-gnome-2.1.1p4-1 but not openssh-server-2.1.1p4-1. And in installation from scratch on another Alpha (not here in the moment) got openssh-server on it. It should be like that? Got confused by complaints from xinetd, which still should be able to resolve the name in question using /etc/hosts. Sigh! (I should take a break for a few days, apparently).