Posts tagged with “”

When SSH Public Key Authentication Fails

I’m no Sys Admin, but I connect to enough Unix machines often enough that enabling public key authentication is a real time saver. For those that may not know, public key authentication allows a user to login to another machine via SSH without a password. I’ve written a bit more about the technique itself in my archive. The other day, in the course of setting up authentication for several machines at work, I noticed that it worked for most of the machines but failed for a few others. After spending a little over an hour checking and double checking the files in my ~/.ssh directory, I spent another hour comparing files on the machines that weren’t working with the ones that were. Everything was precisely the same.

Except that it wasn’t. Evidently I neglected to read my own earlier post, specifically step 5. I had no idea that permissions were such a hot button, but it makes sense. The permissions on my ~/.ssh/authorized_keys file were 664. The boxes wouldn’t let me login because the file was writeable by someone other than me (at least in principle). As soon as I changed the permissions to 644, I was able to connect just fine.

Of course, I realize that this is by design and a very good thing, but I wasn’t expecting it so I stumbled over it.

Mac Owners, Freak Out Someone You Love

My girlfriend works from home on Fridays. I do not. I do, however, leave my Mac powered on and active during the day so that I can SSH in and access files from the office if I need to do so. Last week, knowing that she would be sitting near said computer, I decided to mess with her just a little bit. To do so, I SSH’d into the Mac and used the say command:

$ say "Hello Tricia, this is God. Have you been touching yourself again?"

I personalized the line from Real Genius, but you get the idea. A very nice, disembodied voice that goes by the name of Alex spoke the words aloud as if there was someone in the room with her. She said she jumped about a six feet and had to crawl back into her own skin. She also said that she found Alex’s voice disturbingly sexy. Disturbing to whom?

Tab Completion for CDPATH on Mac

Though I’ve written several shell-related posts, I’m not a shell geek. Let’s get that out of the way right now. The shell is a tool for me and nothing more. I had used tcsh for years and years and years for no other reason than someone told me it was better than bash when I first started doing any “real” Unix work. I recently moved to bash because, frankly, I was tired of having to custom-configure every system I login to on a regular basis. Bash is the default shell for most Unix flavors and since the shell is only a tool, I saw no reason to continue spending time on customizations.

The other day when @patrick_mc dropped a link to a bash mastery article in a tweet, I saw the opportunity to learn something. Though it was hardly a masterful type article, I did learn about one thing that I didn’t know about before: CDPATH.

The details of CDPATH are outside of the scope of this post, but the gist is that it works the way that the PATH works. Type a directory and if it’s in your CDPATH, the OS will find it and change to that directory by name alone – even if the directory name isn’t in your current working directory. For example, if I’m in my home directory, I can type www and be delivered directly to /Users/me/Development/www as long as /Users/me/Development is in my CDPATH.

When I first read the article, I was at work and on my Ubuntu machine so I tried it there first by adding the following line to my /home/me/.bash_profile:

export CDPATH=.:~:~/Development

After sourcing ($ source .profile) my updated profile, I was able to jump to directories exactly as advertised. Moreover, tab completion worked brilliantly so, from my home directory, I could type cd w[TAB] and it would complete to cd www. Brilliant.

It wasn’t quite so easy on the Mac, though. I updated my .profile, but couldn’t get it to work. I thought I had a syntax error in my .profile, but after hours of trial and error, I was no closer. I pinged the #lazyweb on Twitter to ask whether it worked for others on OS X and got more than a few affirmative responses which just confused me even more. A quick chat with Brad Greenlee, though, pointed out the error of my ways. It turned out that CDPATH was working great, but I was assuming (yeah, I know) that tab completion would also work. It didn’t.

For me, something like CDPATH is only useful with tab completion because otherwise, I can tab complete the full path to the file before I can type the entire directory name (for all but the shortest directory names). Besides, the Tab key is completely woven into the fabric of my muscle memory now. I can’t give it up when I’m in the shell. After a little digging, I found the answer:

$ sudo port install bash-completion

Yep, that’s it (assuming you have MacPorts installed). Well, almost. You do have to update your .profile (or .bash_profile, .bashrc, etc.) to source the installed file at /opt/local/etc/bash_completion. Instructions for doing so are printed in the output of the installation. In case you close your window too early, though:

if [ -f /opt/local/etc/bash_completion ]; then
    . /opt/local/etc/bash_completion

Happy completing.

Remove Conflicted Files from Dropbox

Because I use Dropbox to share selected runtime data (read: Firefox profile information) across machines and because I occasionally forget to exit the runtime environment (read: Firefox) when I move between those machines, Dropbox creates conflicted files from time to time. The conflicted files are saved separately and are named something like this:

places ('s conflicted copy 2008-11-13).sqlite

The file above is my Firefox bookmarks database. I have no idea how it came to be in a conflicted state, but the ugly truth is that I don’t care. I assume that Dropbox saves these files as a safety measure against losing their customers’ data and so that the customer can perform a diff on those files if they choose. I don’t choose. I keep convenience files in my Dropbox, not critical files, so the files themselves are not worth the effort it would take to find and evaluate the delta between the “good” file and the conflicted file.

To that end, I’ve taken to simply removing them and because I don’t want to browse the directory structure or do this in any other manual way, I let my operating systems do the work for me. This is easy in Unix and, since two of my machines (my two primary machines) are Unix-based (OS X and Linux), it’s easy for me:

$ cd ~/Dropbox
$ find . -type f -name "* conflicted *" -exec rm -f {} \;

Poof. Now they’re deleted and Dropbox will delete them from my Windows boxes for me. I’m sure that there’s a way to do something similar on Windows, but my DOS skills atrophied many moons ago.

Strip ^M Characters from Files

Because I regularly move between operating systems, I often need to use Windows-created files on Linux. Because of the difference in EOL notation between the operating systems (notice how I carefully avoided any editorial comment on that difference?), that means regularly encountering the ^M character.

While I’ve never found a situation where the character creates a real problem for me, it’s certainly annoying to see those things all over a large file. In the past I’ve used elbow grease and/or various shell scripts to clear these, but today I found out that Ubuntu (probably other distros, as well) offers a utility to do this quickly and easily.

The package is named tofrodos and, while not installed by default, is available in the repository. To install & use:

$ sudo apt-get install tofrodos
$ dos2unix <file to convert>

Couldn’t be easier, right? This is the thing I love best about Linux.

← Earlier Posts Page 1 of 3