Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have three severs A, B, C which all installed debian.

A runing a ssh server.

B can connect to A through ssh, but C can not.

After C was refused by A. B can not ssh to A too!

I have checked /etc/hosts.deny, /etc/hosts.allow, iptables -L, still no any ideas about this problem.

Is there any other settings should I check?

share|improve this question

closed as not a real question by Ward, ThatGraemeGuy, rnxrx, Michael Hampton, Scott Pack Sep 23 '12 at 0:54

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
You should check your log files - and probably post them. This may require physical access to machine A. The list of potential causes for what you are describing is nearly infinite, this question is the technical equivalent of calling your doctor on the phone and saying "My arm hurts. Diagnose and treat me!" -- You could have bumped into a wall and bruised yourself, or an angry badger could be mauling your arm, but there's no way to know which... –  voretaq7 Apr 28 '12 at 1:36
3  
He should check his server for badgers? –  Ward Apr 28 '12 at 1:42
    
By "can not ssh" do you mean connection times out, connection refused before you enter a username/password/key, connection dropped after you try to log in? What does ssh -vvv A say? –  DerfK Apr 28 '12 at 2:31

2 Answers 2

Check NumberOfPasswordPrompts and/or MaxAuthTries in your SSH config file.

You might also have pam_tally2 enabled. Check the login file to see if the deny keyword is included. In RedHat based systems, you would perform: cat /etc/pam.d/login | grep deny

share|improve this answer

I always recommend reverting to the OSI model to structure troubleshooting attempts.

Start with layer 1 but from how the issue is described, perhaps there's a layer 3/4 component? hosts.deny, hosts.allow, and iptables ties to layer3/4 troubleshooting. However, ssh is an application so there may be application-related issues as others have mentioned.

So after C is refused, B can't connect to A. Can you describe more detail what "B can not ssh to A too" means? Can you ping A from B? Can you ping A from C? What about pinging from A to both B and C?

Are A, B, and C on the same subnet? Are they on different subnets?

Is this behavior tied to specific user accounts? Are you using password auth? Have you tried cert-based auth?

Reviewing the pam config and sshd config would also help. What do you see in the log files?

Did this config ever work? Did you make any changes that could have broken something?

Every detail helps when posting such a question, especially on a forum.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.