Linux – RedHat Linux – ssh shows “connection refused” using one user and also root, but another user can connect

linuxnetworkingssh

From server Y, user A tries to ssh to server X and gets Connection Refused.
From server Y, user B tries to ssh to server X and is allowed through.
From server Y, root tries to ssh and gets Connection Refused.
The issue is 100% repeatable and 100% consistent.

The first two would suggest an issue with the ACL, but I'm told the settings are the same for both users although I don't have permission to view them. They have also been deleted and readded without success. However, root isn't affected by the ACL and also cannot connect.

There are two servers with this problem, and many other servers with identical settings in ifconfig (except IP addresses etc) and routing tables that do not suffer this issue.

A tcpdump on server X looking for connections from server Y shows nothing when user A tries to connect, but produces reams of information when user B tries to connect. This shows that server X is receiving nothing when user A is trying to ssh.

All servers are running RedHat

I'm assuming the problem is on server Y, but what should I look for?
Could a username based connectivity issue appear in firewalls in between the servers, or are such firewalls not based on username?

Edit –
Both users A and B can ssh from server Y to many other servers in the group. It is just server X that has the problem. Ssh-ing does not use RSA, although logging in to server Y in the first place does.

Best Answer

Check user A's .ssh/config file. He may have a Host entry in that file for the hostname at issue, which is causing ssh to try a different port or IP address for that hostname. For example, if .ssh/config had these lines:

Host a.example.com
    Hostname b.example.com
    Port 42

Then running "ssh a.example.com" would try try to connect to b.example.com port 42.

Another (unlikely) possibility is that user A is running a different "ssh" program for some reason, e.g. because his command path is different, and the alternate program is not behaving as expected.

Edit: Another unlikely possibility is that you have two hosts on the network answering to the same IP address. The failed connection requests are going to and being answered by the wrong server. This would cause connections to fail randomly, rather than consistently per user, so it doesn't really match the behavior that you describe.

Related Question