Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

SSH is secure enough to not worry about attacks on port 22, right?

After connecting one machine to the SSH server is there a setting in sshd-config or SSH-config files that needs to be changed after creating a key?

share|improve this question

4 Answers 4

Moving sshd to another port is simply security through obscurity. A better approach is to create a layered defense. Start by disabling password authentication and restricting the user list that can login via ssh. Then restrict the source IPs or networks that can connect, and put a throttling rule in place. Make sure that you log failed attempts and inspect your logs regularly. It's even better if you can alert on brute force attacks. There are quite a few tools that can do this.

If you can spare a server to use as a bastion host, then you can remove direct ssh access to your servers, and force all of your clients through one host that you can monitor. Once a client successfully logs in, you can restrict where they jump to by adding outbound iptables rules that are restricted by user or group.

share|improve this answer
1  
Yes and no. Sometimes restricting source IP's is not appropriate. I found this once. We were getting a lot of probes and port scans on port 22. I moved it to another port and the problem went away. Which meant not so much of the probing filling up in the log file. It was still secured SSH, but the probes were annoying. –  Matt H May 3 '11 at 4:42

If you disable password authentication, then you're in pretty good shape. If you allow it, use fail2ban to stop brute force password hacks. You will get them on an open ssh port.

share|improve this answer
    
disabling password authentication only allows keys, right? –  winchendonsprings May 3 '11 at 2:23
    
User keys, correct –  uSlackr May 3 '11 at 2:45
    
+1 for fail2ban - its an awesome little bit of software, and pretty much takes the teeth out of brute force attacks –  Journeyman Geek May 3 '11 at 3:40
    
since I will only connecting from one computer and if I turn off passwords auth and restrict users then fail2 ban wouldn't be needed, correct? –  winchendonsprings May 3 '11 at 4:49

If you disable passwords that should be fine. You can also restrict user accounts in the sshd_config file.

MaxStartups 3:60:8
AllowUsers myaccount

As a further restriction. you can also restrict hosts that can connect, but you might not want to do that.

The MaxStartups is my attempt at a simple form of connection "tarpitting", but I'm not sure how well it works.

share|improve this answer
    
I'm not sure how the MaxStartups works but restricting users seems like what I need. –  winchendonsprings May 3 '11 at 4:51

With regard to brute force attacks, here is a simple rule to set up with Iptables:

# we create a new chain for bruteforce attack detection
iptables -N BRUTE

# allow 10 new connections in a timeframe of 60 seconds
iptables -A BRUTE -m recent --set --name CHECK --rsource
iptables -A BRUTE -m recent --update --seconds 60 --hitcount 10 \
  --name BRUTE --rsource -j DROP

# add a rule in the INPUT chain to check for SSH against the BRUTE chain
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j BRUTE

This works with the Iptables module "ipt_recent," which actually stores a file within "/proc/net/ipt_recent/name" (in this case name is BRUTE).

These rules will allow new connections in a delay of one minute from the same IP, otherwise it will be blocked temporarily and the IP has to stop new connection attempts against the service. While it is very simple to set up unlike fail2ban it doesn't allow for a distinction between successful connections and failed attempts.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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