ssh with DSA authorization keys; folder permissions and other easy to miss problems

ssh without passwords is usually easy to do, e.g., using ssh-keygen as per here, but I have come accross some issues a couple of times recently.

1: Make sure the ~/.ssh/authorized_keys file is spelled correctly, i.e., don’t spell it “authorised”. Easy to do with Australian or British English.

2: Make sure the .ssh folder and its contents have the correct access permissions. The folder on the remote host I was wanting to connect to didn’t have the correct permissions. A quick chmod -R 755 ~/.ssh did the trick.

Thanks to this Arch Linux forum entry.


Emacs spell checking (aspell) in Arch Linux

I just tried to use the flyspell module in emacs for the first time after my new Arch Linux install. I got this error message:
Error: No word lists can be found for the language “en_US”

It turns out that my aspell-en package had either not been installed or was uninstalled at some stage. Re-installing it with:
sudo pacman -S aspell-en
fixed it 🙂

Thanks to

Set default program to open files in Arch Linux

I am currently using Arch Linux as my work OS. I have found Google’s Chromium browser to be far better than FireFox. I never thought I’d say that, but Chromium is excellent under Linux now.

I was finding that the default program that Chromium was using to open pdfs was FireFox with the acroread plugin; strange, but each to their own… It turns out that Chromium just uses the xdg-open command to load files with the user’s preferred applications. How to choose these preferred applications? The xdg-mime command must be used, e.g., to set acrorread as the deafault pdf reader:

xdg-mime default acroread.desktop application/pdf

However, I noticed that when I first tried this, I received four error lines telling me that various processes couldn’t access the configuration file:

/usr/bin/xdg-mime: line 625: /home/kris/.local/share/applications/ No such file or directory
grep: /home/kris/.local/share/applications/ No such file or directory
/usr/bin/xdg-mime: line 627: /home/kris/.local/share/applications/ No such file or directory
/usr/bin/xdg-mime: line 629: /home/kris/.local/share/applications/ No such file or directory
mv: cannot stat `/home/kris/.local/share/applications/’: No such file or directory

This was easily fixed by manually creating a blank file in that directory which (I had to manually create the applications folder, but the ~/.local/share folder already existed for me). Now it seems xdg-utils works like a champ.

To make opening using default programs in the terminal a little easier, I created an alias in my ~/.bashrc by adding the line:

alias open=’xdg-open’

so that all I have to do is say open [file] and it opens the file in my preferred application set using xdg-mime default [application].[environment] [filetype].

Full worked example:

What about determining the filetype of a given file, determining the application it is opened with by default and then changing the default program? I just did this when I realised I didn’t have a program set to open locally saved/cached html files.

Say the local file is called test.html. To determine the filetype xdg associates with this file, run:

xdg-mime query filetype test.html

The output was:

text/html; charset=utf-8

So that the filetype is text/html. To determine the current program set to open this filetype, run:

xdg-mime query default text/html

I received a blank line after this; there was no default application set. To set a default application (e.g. the Google the Chromium browser), run:

xdg-mime default chromium.desktop text/html

… and that’s it. Now the command xdg-open test.html will open test.html in the Chromium browser. Again, if you bound xdg-open to just open as I showed above, you just need to type open test.html for the same result.

Programs I have recently installed

A short list of some neat programs I have recently installed in my work Arch linux setup:

planner for Gantt charts
cmus for music
OpenOffice 3 (starts with the soffice command, looks v. nice)
Midnight Commander nCurses file manager (mc)

reverse mapping checking getaddrinfo for xxxxx [] failed

I had recently been getting a very slow (10 sec) ssh login time when accessing my home server from work. After checking my /var/log/auth.log file I found this error:

warning: /etc/hosts.allow, line 15: can’t verify hostname: getaddrinfo(, AF_INET) failed

where is the DNS name the ssh request returns when querying my work machine (actually the firewall/proxy address — as we’ll see). This particular error was fixed when I changed the host name for the host I had listed in my /etc.hosts.allowed file to a bare IP, not a DNS name. I still want to see if this can be worked around. I then unmasked the real problem after logging in again:

reverse mapping checking getaddrinfo for [] failed – POSSIBLE BREAK-IN ATTEMPT!

It turns out that, I guess because my work likes to keep my behind a proxy and firewall, that a reverse DNS request back to my work computer didn’t match the IP from which the ssh login attempt was sent. To fix this I just added the “” (not the real name) to my /etc/hosts file in order to map the host name back to my real IP. I added a line like this to my /etc/hosts file:

where is the IP address of my work machine.

Incidentally, since my machine was behind a firewall/proxy, I had to determine its “real” external IP using the great site: The “IP Adress” item gave the IP of the firewall/proxy server, which is of no use when a DNS callback is wanting to find my machine. The “X-Forwarded-For” item, however, gave an external IP address for my actual machine; this was the IP I used in the hosts file above.

Thanks to ElectricToolbox for the tips!

I can now ssh in to my home server from work almost instantly.

Remove orphaned packages in Arch Linux

A one-liner to removed orphaned packages and their dependencies that aren’t required by other packages:

pacman -Rs $(pacman -Qqtd)

$(pacman -Qqtd) provides a list of orphaned packages.

-Rs removed these packages and their dependencies that aren’t required by other packages.

From Phlogi: second reply here.

Nice ^_^

GNU Screen and the scrollback buffer

Some great GNU Screen tips in Arch Linux: here.

A great post on GNU Screen and the scrollback buffer: here.