To be fair he's not saying that. He's saying that he's concerned about the increase in complexity of the SSH2 code base. Given that was 4 years ago I'd be surprised if the SSH2 code base hasn't been thoroughly audited by the team.
I think it was a valid concern to have if SSH2 hadn't been audited at the time, given that you're trading known issues for an unknown solution that may or may not work, but to infer he thinks SSHv1 is more secure than SSHv2 in that post is slightly inaccurate.
As a total Linux n00b, I was given the advice to also run SSH on a non-standard port 4 digit port like 4232 instead of 22. I don't know how effective that is, but it sounded like good advice to me.
Running SSH on a different port sounds like good advice because the automated scanning tools tend to focus on port 22.
However, if you're vulnerable to the scanners then you haven't actually addressed the vulnerability they exploit. What you're looking at is a form of security by obscurity that reduces the number of low end attacks, but if someone port scans you, finds the SSH port and runs the same attacks you're still going to get compromised.
Another thing to consider is that if you're moving SSH ports your OS will still respond to requests to connect over SSH by telling the scanners that there's no SSH service running on that port. If you're being metered for bandwidth by bytes transferred it shouldn't be a lot (unless you're getting really hammered by it, which tends to happen when the IP address has been previously compromised).
The correct way to deal with this is to use only public key authentication (which stops people getting in through password brute forcing) and to block the port with a firewall with exceptions for the places that you access it from. You can find out where you're accessing it from by going through the SSH logs.
By all means swap ports if you want to, but don't rely on it alone.
This isn't really a configuration suggestion, more of an architecture suggestion: let's say you're like me and you have 5 VPSes. You want precisely one to have SSH exposed to the public Internet. Everybody else has SSH only listen on a private IP. (Your host can probably set those up for you. Slicehost does, for example.)
e.g.
ListenAddress 1.2.3.4 #This is not really your IP address.
You can go an extra step and drop all packets to the SSH port on the public interface in IPTables, if you want. It strikes me as being overkill but, hey, whatever.
If you need to log into any server, you do so by tunneling through your gatekeeper server. That fellow gets locked down tightly. All of your other servers are firewalled tight as drums, with the exception of public-facing HTTP servers who have 80 and 443 opened (and that is it).
This is sound advice and I've seen this in quite a few small multi-server environments. The only thing I'd say is that once you get to 5 - 10 servers you might want to look at a VPN such as openVPN (http://www.openvpn.net/), at which point all your SSH services can run on their hidden networks.
This makes a bigger difference as well if you have more than a few people accessing the boxes, and for purely remote-based businesses quite a few use this type of setup to host their 'internal' network tools like an intranet, file storage, internal wiki etc.
If you have the cash and capability, I'd recommend an IPSEC VPN over OpenVPN (using something like a low-end Cisco ASA for example, but shop around - the point is to use dedicated hardware), but if you're starting out, OpenVPN is fine.
Don't you sudo on remote machines. Disable it.
Disable 'su' as well
Only allow root login from remote with a key: PermitRootLogin without-password
Attacker can sniff the user's pass or hack the user's home machine and now can execute commands as root.
If you need you users to execute with privileges use another mechanism than sudo
If you're going to use weird ssh-hiding tricks like alternate ports, gateways, or port-knocking, be sure to read all about what you can do with ~/.ssh/config
Host securebox
#if not proxying
HostName securebox.tld
Port 1023
User fji00random
#if going through a gateway
ProxyCommand ssh gatewaybox.tld nc securebox.tld 22
#if knocking
ProxyCommand proxyknock %h %p 1337 1337 900
(and for systems without a knocker installed, you can use something like http://sprunge.us/HJHB for proxyknock, which can be cloned along with the rest of your dotfiles/scripts)
And if you're doing public key auth, read about ssh-agent, it can store your private keys in memory so that you don't have to retype your passphrase all the time, while the "physical" key is still protected if stolen.
In my bash_profile, I have
SSHAFILE=/tmp/.$(whoami)-ssha
if [ -n "$SSH_AUTH_SOCK" ]; then
echo "We has auth!"
elif [ -f $SSHAFILE ]; then
. $SSHAFILE
else
eval `ssh-agent | tee $SSHAFILE`
chmod 600 $SSHAFILE
ssh-add
fi
This runs ssh-agent if it's not running, and sets proper env variables if it is.
(also, the ssh-agent can be forwarded, so you can use your private key to auth into box C, from box B, while the key is only on your local box, A - this can also be added to your .ssh/config)
This is also good advice. I didn't want to put it in as I just wanted it to be an explanation of my own position on port munging and to keep it fairly simple, but ssh-agent is a great way of making multiple ssh accesses easier.
12 comments
[ 2.7 ms ] story [ 33.3 ms ] threadhttp://www.ossec.net/dcid/?p=10
I think it was a valid concern to have if SSH2 hadn't been audited at the time, given that you're trading known issues for an unknown solution that may or may not work, but to infer he thinks SSHv1 is more secure than SSHv2 in that post is slightly inaccurate.
However, if you're vulnerable to the scanners then you haven't actually addressed the vulnerability they exploit. What you're looking at is a form of security by obscurity that reduces the number of low end attacks, but if someone port scans you, finds the SSH port and runs the same attacks you're still going to get compromised.
Another thing to consider is that if you're moving SSH ports your OS will still respond to requests to connect over SSH by telling the scanners that there's no SSH service running on that port. If you're being metered for bandwidth by bytes transferred it shouldn't be a lot (unless you're getting really hammered by it, which tends to happen when the IP address has been previously compromised).
The correct way to deal with this is to use only public key authentication (which stops people getting in through password brute forcing) and to block the port with a firewall with exceptions for the places that you access it from. You can find out where you're accessing it from by going through the SSH logs.
By all means swap ports if you want to, but don't rely on it alone.
e.g.
ListenAddress 1.2.3.4 #This is not really your IP address.
You can go an extra step and drop all packets to the SSH port on the public interface in IPTables, if you want. It strikes me as being overkill but, hey, whatever.
If you need to log into any server, you do so by tunneling through your gatekeeper server. That fellow gets locked down tightly. All of your other servers are firewalled tight as drums, with the exception of public-facing HTTP servers who have 80 and 443 opened (and that is it).
This makes a bigger difference as well if you have more than a few people accessing the boxes, and for purely remote-based businesses quite a few use this type of setup to host their 'internal' network tools like an intranet, file storage, internal wiki etc.
If you have the cash and capability, I'd recommend an IPSEC VPN over OpenVPN (using something like a low-end Cisco ASA for example, but shop around - the point is to use dedicated hardware), but if you're starting out, OpenVPN is fine.
And if you're doing public key auth, read about ssh-agent, it can store your private keys in memory so that you don't have to retype your passphrase all the time, while the "physical" key is still protected if stolen. In my bash_profile, I have
This runs ssh-agent if it's not running, and sets proper env variables if it is.(also, the ssh-agent can be forwarded, so you can use your private key to auth into box C, from box B, while the key is only on your local box, A - this can also be added to your .ssh/config)