Using different usernames on a Mac over SSH

When I switched to a Mac recently, one of the things I loved about it was the underlying Unix shell. One of the most frequent things I do in a day is connect to a web server over SSH to do routine things (set permissions, edit a file, remove something, etc.). In Windows, I used PuTTY, which is a great terminal program; but I have spent some serious time setting up shortcuts and Windows hotkeys to get PuTTY to act as a native SSH client.

Tobby Hagler, Director of Engineering
#Development | Posted

When I switched to a Mac recently, one of the things I loved about it was the underlying Unix shell. One of the most frequent things I do in a day is connect to a web server over SSH to do routine things (set permissions, edit a file, remove something, etc.). In Windows, I used PuTTY, which is a great terminal program; but I have spent some serious time setting up shortcuts and Windows hotkeys to get PuTTY to act as a native SSH client. One of the features that I like about the Mac is that I really do have a native SSH client.

 

One annoying detail, however small, is that the username on my Mac is different than the various usernames I have on the servers I visit frequently. This means that in my terminal command, I must specify the username of the account I’ll be connecting as to keep it from sending my local username. So, ssh example.com becomes ssh remoteuser@example.com. It’s not like it’s that difficult; but it’s something that I forget to do frequently enough to be a source of frustration.

 

So like with most annoying things, I googled it and found a solution (this will apply to Mac and Linux users alike).

 

First, you’ll want to edit /etc/ssh_config:

  1. <br />
  2. $ sudo nano -w /etc/ssh_config<br />

 

As the filename suggests, this file contains all the configuration for your SSH client. Most likely, it’ll be empty (save for a bunch of comments and sample settings). Go to the bottom of this file, and add:

  1. <br />
  2. Host *.example.com<br />
  3. &nbsp; User username<br />
  4. &nbsp; ServerAliveInterval 300<br />

 

Optionally, you can add IdentityFile ~/.ssh/identity_username in that block too, if you feel like setting up SSH keys (which I highly recommend).

 

The Host line sets up a block of configurations that will apply to the host you will be connecting to. It takes wildcards, so if you have a setup like development.example.com, qa.example.com, and production.example.com, it’s worth setting up with wildcards.

 

The User line is the key here. If your local username is uname, but your remote server username is user.name, you’ll put user.name here. This prevents you from having to prepend user.name@ before the hostname when you connect on the commandline.

 

ServerAliveInterval isn’t necesary, but it’s nice to have. Every 300 seconds, it will tell your remote server that you’re still connected, and not to automatically drop you. CAUTION: This can pose a security risk. If you leave your local machine unlocked and unattended, someone can come behind you and gain access to anything you’re connected to.

 

You can create many Hosts blocks, one for each server (or group of servers). This way, you can have a different username for every single server you connect to, and you’ll never have to remember to pass the remote username on the commandline.

 

Optional

 

Something else you can do is add an entry to your /etc/hosts file. If you have something like development.somereallylongdomainname.com, you may want to shorten it, so that all you have to do to log in is ssh dev.

  1. <br />
  2. $ nslookup development.somereallylongdomainname.com<br />
  3. $ sudo nano -w /etc/hosts<br />

 

In this file, add a new line like 1.2.3.4 shorthost, where the IP address is the Address given by nslookup, and shorthost is whatever name you want to call it.

 

Now, all you have to do is type ssh shorthost and you’re immediately connected.

Tobby Hagler

Director of Engineering