ssh

SSH into a Raspberry Pi with only a network cable using OS X's 'Internet Sharing'

Recently, I found myself in a situation where I had to connect to a Raspberry Pi to set it up for a presentation, but I did not have:

  • A keyboard and/or other input device to use to type anything into the Pi
  • An HDMI cable to connect the Pi to a display so I could view anything on the Pi
  • A microSD card reader so I could modify the contents of the Pi's microSD card

Because of this, none of the standard methods of setting a static IP address, reconfiguring the Pi's WiFi configuration, or logging in on the Pi itself to find it's IP address or set things up so I could connect over a local network would work.

I remembered that Mac OS X handily includes an 'Internet Sharing' feature, which sets up a bridged network interface so your Mac is effectively a router and DHCP server to any devices connected to the shared interface.

Fastest way to reset a host key when rebuilding servers on the same IP or hostname frequently

I build and rebuild servers quite often, and when I want to jump into the server to check a config setting (when I'm not using Ansible, that is...), I need to log in via SSH. It's best practice to let SSH verify the host key every time you connect to make sure you're not getting MITMed or anything else is going on.

However, any time you rebuild a server from a new image/OS install, the host key should be new, and this will result in the following message the next time you try to log in:

A brief history of SSH and remote access

This post is an excerpt from Chapter 11: Server Security and Ansible, in Ansible for DevOps.

In the beginning, computers were the size of large conference rooms. A punch card reader would merrily accept pieces of paper that instructed the computer to do something, and then a printer would etch the results into another piece of paper. Thousands of mechanical parts worked harmoniously (when they did work) to compute relatively simple commands.

As time progressed, computers became somewhat smaller, and interactive terminals became more user-friendly, but they were still wired directly into the computer being used. Mainframes came to the fore in the 1960s, originally used via typewriter and teletype interfaces, then via keyboards and small text displays. As networked computing became more mainstream in the 1970s and 1980s, remote terminal access was used to interact with the large central computers.

Connect to IRC via Adium when connected through an LTE hotspot

When I'm on the go, I like to use my iPhone 5s as a hotspot, as I get 10-20 Mbps up and down (much better than any public WiFi I've used), and it's a more secure connection than a public, unsecured hotspot.

However, when I open Adium, I'm greeted with:

Notice -- You need to identify via SASL to use this server

To fix this, I forward port 6667 on my Mac to one of my remote servers using SSH, then tell Adium to use that server's connection with my Mac as a SOCKS5 proxy. If you need to do this, you can do the following:

  1. We need to forward port 6667 from your local Mac to a remote server ('example.com') to which you have SSH access. In Terminal, enter: ssh -D 6667 [email protected]
  2. In Adium, go to the IRC connection settings, and under Proxy, check the 'Connect using proxy' checkbox, choose 'SOCKS5' for Type, enter 'localhost' for Server, and '6667' for Port (see screenshot below).

Adium SOCKS5 proxy settings for IRC tunnel on port 6667

Fixing SSH unknown error when provisioning a Vagrant VM with Ansible

While getting a local VM managed by Vagrant to work with Ansible for provisioning, I kept getting errors like the following:

fatal: [solr] => SSH encountered an unknown error during the connection. We recommend you re-run the command using -vvvv, which will enable SSH debugging output to help diagnose the issue

[vm-name-here] : ok=0    changed=0    unreachable=1    failed=0

FATAL: no hosts matched or all hosts have already failed -- aborting

Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

It seems that Ansible is unable to connect to the VirtualBox host via SSH because the entry for 127.0.0.1 in my ~/.ssh/known-hosts file is set for my local computer, and not for any VMs. To work around this limitation, I created a new file, ~/.ssh/config, with the contents:

Host 127.0.0.1
        StrictHostKeyChecking no
        UserKnownHostsFile=/dev/null

Now, when Ansible tries connecting during provisioning, it doesn't check the host key for localhost, and provisioning succeeds.

Running Vagrant + VirtualBox from an External Drive

I have a MacBook Air with a 128 GB SSD, so I'm always in a bit of a crunch for space on my hard drive. Developing with local VMs provisioned by Vagrant and VirtualBox makes my Drupal (and other) development experience great, but it also quickly fills up the (tiny amount of) remaining space on my SSD!

Here's how you can move your Vagrant files and VirtualBox VMs out of your home folder onto an external hard drive:

Fixing Problems with Passwordless SSH Authentication

I use CentOS, but these guidelines should apply no matter what flavor of linux you use. We all know it's a good security practice to lock down your server and require SSH logins to use an RSA key/pair, rather than a password, right? Plus, it makes it easier for you to login to your server from your primary computers/devices...

I was setting up a new server recently, and spent probably half an hour figuring out why the standard way of creating a shared key, sending it to the server, putting it in /home/[username]/.ssh/authorized_keys, and trying to log in without a password wasn't working for me.

It turns out, there were permissions issues I hadn't thought of (I usually would create accounts through cPanel, since I only live in the Terminal out of necessity, from time to time). When you create the authorized_keys file, which contains public SSH keys for your computers, you need to make sure the permissions are set so that:

Arrow and Command Keys Not working in Ubuntu 10.04 for non-root Account

For some time, I was having trouble getting the arrow keys to function correctly in my terminal sessions when logging into one of my remote Linode servers running Ubuntu 10.04. Whenever I pressed an arrow key, instead of moving the cursor or going up and down the command history, I would get a string of gibberish like [[A^[[B^[[D^[[C. Not very helpful!

So, after some searching, I found that the cause for this is an incorrect shell environment being set in the passwd file. To fix this problem, simply edit the /etc/passwd file and change the final string (after the last :) to /bin/bash (it is set to /bin/sh if you create a user via the command line/useradd):

$ sudo nano /etc/passwd

Change this:
<username>:x:1000:1000::/home/<username>/:/bin/sh

to this:
<username>:x:1000:1000::/home/<username>/:/bin/bash

...and then save the file, log out, and log back in. Problem solved!

iSSH on the iPad - SSH and VNC from Anywhere

[UPDATED: The developer of iSSH emailed me this morning with a couple of tidbits that will be useful for any early iSSH adopters on the iPad - see my updated notes in bold.]

One app I haven't had a lot of time to work with (yet) is iSSH on the iPad. I tried the iPhone version, but the tiny iPhone screen simply couldn't keep up with a productive SSH or VNC session.

The iPad changes the game, though; I can actually log in via SSH, do some real work, then go back to doing whatever I was doing on the iPad. Since the iSSH developers didn't have a ton of time to work on an actual iPad, there are some pretty annoying bugs right now—but these bugs will be fixed soon. Some of the bugs:

SSH in a Locked-Down Network

Recently, during one job for a client, I needed to work for a length of time in a location that had quite severe network restrictions—in addition to a proxy server, the location blocked every port besides 80, 25, 443, and 8080. In order to use secure shell (SSH) to login to my work web server, I needed to use one of those ports (I used nmap to find open ports on my end).

Luckily, I gained access to another network for a short time, and used that connection to update my work web server to allow SSH over port 8080 (in addition to the standard, port 22). I edited the /etc/ssh/sshd_config file so it reads:

Port 22
Port 8080

(the Port 22 line was commented out, originally).

Then I simply used the -p (port) directive when logging in via SSH:

$ ssh -p8080 [email protected]