ssh

One of Ansible's strengths is the fact that its 'agentless' architecture uses SSH for control of remote servers. And one classic problem in remote Git administration is authentication; if you're cloning a private Git repository that requires authentication, how can you do this while also protecting your own private SSH key (by not copying it to the remote server)?

As an example, here's a task that clones a private repository to a particular folder:

If you run this task, you'll probably end up with something like:

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.

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:

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:

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).

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.

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:

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:

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!

[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: