Archive for the ‘ssh’ Category

Securing your SSH on Centos, especially on EC2.

Posted on December 6th, 2012 in AWS, security, ssh | No Comments »

The popular port.

Example brute force attempt on an EC2 server.

By default SSH runs on port 22 on your server. Though I’m not a proponent of security by obscurity, moving your SSHd to a high-number port (like 3293) will reduce the number of brute force attempts on your SSH by nearly 100% (Stats given by reviewing /var/log/secure on servers I have or have had access to for years.) This used to be pretty important but even more so with cloud services like Amazon EC2 where hackers and script kiddies can ping sweep whole subnets of Amazon’s elastic IP ranges. (On a related note, Stackoverflow blocked all EC2 instances from accessing their site using the same approach.)


If for some reason though, you cannot move SSH ports—for example, you’re working in a legacy system where dozens or hundreds of people are already connecting to, the next best thing is to install DenyHosts, a free tool written in Python that reviews and bans IP addresses that make too many failed attempts.

Installing DenyHosts

Centos doesn’t have direct access to installing it. But you can install it by running the following:

sudo rpm -Uvh
sudo yum install denyhosts

After that, add your IP address to /etc/hosts.allow in the format of sshd: so that it will never blacklist your IP, tweak /etc/denyhosts.conf to your liking, and restart denyhosts with sudo service denyhost restart. It started analyzing your /var/log/secure and banning ips pretty instantly as you can see from this screenshot. After a few weeks it can optionally purge them so the ban list doesn’t get super big.

DenyHosts auto blocking IP addresses.

The folks at Digital Ocean have a great entry that can walk you through the rest.

Note: The one downside of switching SSH ports is that you can no longer use git in it’s common syntax since git uses SSH as it’s secure transport. See my article on using git on non-standart ports to solve that easily.

Hardening your /etc/ssh/sshd_config

There are a few adjustments you should make to your SSHd config so that it’s harder for the wrong person to gain access. This includes disabling password-based logins (everyone should be using SSH keys), disabling root user login, and throwing in a welcome message that this SSH session is being logged:

# Disable password based login. Only SSH keys are allowed.
PasswordAuthentication no
# Add a message banner notifying this server is logged.
Banner /etc/ssh.go.txt
# Do not allow root to login
PermitRootLogin no
# Deny root user login
DenyUsers root

Following the above steps should make your SSH more secure. Happy SSHing!

Refresh a stale tmux session

Posted on March 31st, 2011 in ssh, tmux | 3 Comments »

Sometimes when you SSH into a machine and reattach your tmux session you’ll find that your SSH environment variable is stale so commands like “git pull” don’t work. Here’s a simple command that refreshes that variable. I simply type “r” anytime I notice my session is stale or a command requiring ssh authentication fails:

# used to refresh ssh connection for tmux 
function r() {   
  if [[ -n $TMUX ]]; then
    NEW_SSH_AUTH_SOCK=`tmux showenv|grep ^SSH_AUTH_SOCK|cut -d = -f 2`
    if [[ -n $NEW_SSH_AUTH_SOCK ]] && [[ -S $NEW_SSH_AUTH_SOCK ]]; then 

I can’t take credit for this wonderful tidbit, it was written by Eivind Uggedal in a comment in this post.

Working with git repos on non-standard ports

Posted on March 30th, 2011 in git, ssh | 8 Comments »

Recently due to some SSH attacks I’ve had to change my default SSH port to something non-standard. While I’m not a proponent of security through obscurity, most automated botnets ping random IP addresses on port 22 to see if there’s an SSH daemon listening before relentlessly hammering down on them—it only makes sense to get off of that port. (I’ve obviously hardened my security in other ways as well.)

Since I run my own little version of GitHub (using a combination of Gitolite, git-commit-notifier, and other open-source tools) which I share with friends, I needed to send out a quick email on how to switch up existing checked-out repositories as well as how to clone new ones using this non-standard port. Since I did the research, I thought I might as well post it here, too:

Cloning a git repository on a non-standard port

The git man file says you can specify a port using the traditional git syntax but I couldn’t get it to work for the life of me, It always defaulted to port 22. Since git just uses SSH anyways, here’s the alternative syntax that also works:


git clone<project name>


git clone ssh://<port>/<project name>

Switching an existing checked-out repository to use a non-standard port

To prevent having to re-checkout an entire project, simply change the location of master and all will be fine. There’s a way to do this using a git shell command but I prefer to just modify the .git/config file directly, as that’s all the commands does anyways.


[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url =<project name>


[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = ssh://<port>/<project name>

Set it and forget it method (.ssh/config)

Instead of doing any of the above, if you’re on a Mac or Linux environment, the config file inside of your ~/.ssh folder can save you from typing long ssh commands. It allows you to create short ssh alias’s that predefines a host, username, port, as well as more advanced functionality like running proxy commands, forwarding your ssh agent, etc. It’s well worth taking a look at. When you set an SSH alias anything that uses SSH (git, rsync, scp, etc) all have access to it.

Add the following lines to your ~/.ssh/config:

Host myrepo
     User git
     Port <port number>
     Hostname <>

Now you can do a git clone by doing the following:

git clone myrepo:<project name>

Or in your current checked-out project change the remote “origin” url to:

myrepo:<project name>

It will automatically pick up your username, port, and hostname from your .ssh/config file.

Solution to SASL error while joining IRC from a tethered mobile device: *** Notice — You need to identify via SASL to use this server

Posted on February 25th, 2011 in irc, ssh | 4 Comments »

Update: Apparently this has been fixed in the next Desktop and Mobile version of Colloquy. I found someone linking to this very article in the support ticket. If you want a fixed version now you must build from source, or else just wait until the new version is released and follow the steps below.

I use Colloquy on the Mac to connect to the company IRC channel on freenode. IRC is such an old technology but I find its pretty great for daily company communication. Also when a few people are working on a project together, they can just create a passworded room for quick intercommunication. The only thing it lacks from my previous employer’s method of using Skype rooms is proper logging / history for when you’re not logged in. Still, I generally dig it’s simplicity and people can email if you’re not around. Additionally, I gain the benefit of joining the #emacs or #html5 (etc) channel when I need to solve a quick problem.

During my daily Caltrain commute from SF to Palo Alto, I generally join the chatroom through a tethered iPhone 4. This used to be effortless but in the past two days I’ve been blocked by this strange error:

NICK krunkosaurus
USER krunkosaurus 0 * Anonymous User
NOTICE * *** Looking up your hostname...
NOTICE * *** Checking Ident
NOTICE * *** Couldn't look up your hostname
NOTICE * *** No Ident response
433: * krunkosaurus Nickname is already in use.
NICK krunkosaurus_
NOTICE krunkosaurus_ *** Notice -- You need to identify via SASL to use this server
ERROR Closing Link: (SASL access only)

I did some Googling, and it’s as if Colloquoy thinks I’m going through a TOR server or the like. Googling more I found this tweet where a guy was having the same error on a tethered T-mobile (I’m on AT&T). A member of Colloquy told him to try using an SSH tunnel. (Turns out the real issue seems to be that the IRC clients are trying to connect to your mobile carrier instead of the IRC server – it happens to me on all IRC clients including Adium.)

Anyways, the fastest solution for me was creating a SOCKS proxy via Adium (Colloquy doesn’t have built-in SOCKS support but you can apparently just do regular port forwarding). You do need SSH access to a remote server in either case. The steps are as follows:

1) Open up terminal and type: ssh -vD 6667
2) Open up Adium and go to File > Add Account > IRC
3) Fill in handle and chatroom details
4) In the Proxy tab, checkmark “Connect using proxy” and specify SOCKS5.
5) Server is “localhost”. Port is: 6667.

You should now be able to connect.

Tip: Don’t save this with autoconnect unless you’re always mobile. Instead save this as your “mobile” Adium account which you can switch to from your regular account when you are tethering.