tail -f findings.out

When hanging out in Windows land, life is pretty rough without PuTTY. And while PuTTY is awesome, it too is missing a few nice features. One noticeable default lack is the inability to open multiple tabs with sessions in a single window, as is common for terminal applications on Linux and OSX.

Luckily, there is the PuTTY Connection Manager! This serves as a container that spawns PuTTY processes. It not only allows tabs, but also a nice view of saved sessions, automatic login ability, import and export of your encrypted config database, and more!

I had some problems using Launchy on Vista a while ago (slow, crashed), but the latest version has been working like Ajax on the plains of Scamander. I won’t go into the details of Launchy here, as much has been written about it. Basically it is an awesome keystroke launcher, similar to Quicksilver, Gnome-Do, and the like.

There are some plugins for Launchy that expands what it can do, and one super handy one is the PuTTY Plugin. You will need to exit out of Launchy before running the installer. After you install it, go into Launchy’s Options, then Plugins, then PuTTY. Check the “Add session names directly to catalog” option. Now you can get Launchy to open a session for you based on whatever names you have assigned in PuTTY! So now with something like “mycoolserver” + enter, you are logged in. Couldn’t be much faster unless you assigned a keyboard shortcut to login to your servers, which only works if you have a few.

While setting up Tortoise recently, I couldn’t easily find how to tell it I wanted to use keys for SSH authentication. This post helpfully described how Tortoise actually uses PuTTY for its SSH connections, and how to get key-based auth working. In essence, you connect to your SVN server with PuTTY, then you use the saved session name when doing the checkout via Tortoise. This way you can define what key and user you want to use, and Tortoise won’t bother you for them again.

My last post was on how I used Samba to share files from my central media server to other machines on my local network. Seemed great at first, but having used it for a little while, I was rather disappointed. I had Rhythmbox looking at the mounted drive as my library. It started scanning the files once the directory was mounted. I could play them, but after a few minutes, Rhythmbox would freeze scanning the files. In addition, I could not even list the directory that contained the mounted directory. Something was getting frozen. This kept happening more and more, and was quite frustrating.

I then tried of SSHFS for the same purpose, and it has been working much better. If you can SSH to the machine with the files you want to share, then you don’t have to make any changes to that computer. Just a few steps on the machine that will be accessing the remote store, and you are ready to go. From the top:

• Create the dir which to which the remote dir will be mounted (e.g. /home/myuser/Music)
• Make sure you have ssh access on remote machine from the local machine
• On the local machine:

  • 1	sudo apt-get install sshfs

  • 1	sudo modprobe fuse

  • 1	sudo usermod -G fuse -a youruser

  • 1	sudo chgrp fuse /dev/fuse

  • Logout of myuser on the local machine, then back in

  • 1	sshfs 192.168.1.6:/dir/on/remote/server LOCALDIR

will make sure you have that kernel module loaded. You have to be in the fuse group to perform the mount, sudo or not. I am not exactly sure why you have to change the group of the fuse device, but you definitely have to to get it to work.

At this point, you should be able to view all the files in /dir/on/remote/server from LOCALDIR. Performance wise, I had great success. Pointing Rhythmbox to the dir I mounted, it scanned all the files in a timely manner, and I was able to play them as if they were on the local machine without issue.

If you wish to unmount the share, run

. One problem that has been suggested for which I do not have a fix yet is how to handle if the remote machine has a problem, reboots, or the network connection is otherwise dropped. I am not sure how this would be handled, since the mount would no longer work. fuse being a kernel module, this may cause freezing. If I find this addressed somewhere, I will post it.

Additional information and links:

• General HowTo
• Good reference
• Post on changing /dev/fuse owner

After living with DenyHosts for some time, I have made some additional configuration changes that are quite helpful.

1. Whitelist known good IPs
   I found after not very long that my home IP address had been added to my webserver’s hosts.deny file by DenyHosts. This was a result of having messed up my own login a few times. This could easily be an issue if you are regularly connecting to the box running DenyHosts (from work, home, etc).
   A simple solution: Add your IP to an allowed-hosts file in your DenyHosts working directory. Once that is in place, you might also need to find and remove the entry for the IP in question from your hosts.deny file (if it has already been added). It would be a wise choice to add known good IPs to allowed-hosts when you first setup DenyHosts. Otherwise, you might find yourself blocked from your server with no way to get access!
   For more details, see the FAQ.
2. Blacklist bad users
   It is also a good idea to add users you know are not allowed in a restricted-usernames file in your DenyHosts working directory. This keeps users that should never be allowed to login from trying, even once. There are two handy scripts provided to help in generating this list (located in the scripts dir of your DenyHosts working dir).
   The first, restricted_from_passwd.py, scans your /etc/passwd file and outputs users who have nologin set (print daemons, etc). You can redirect this to your restricted-usernames file.
   The second script is only handy after you have been running for some time. restricted_from_invalid.py, when passed your working dir, prints out the users which bad SSH attempts use most often. By default, it prints the top 10. You could also pass it a large number, say 10000, and it would print all the bad users ever attempted since DenyHosts was first started. I take this list, remove the users I have in place and know to be good, and use it as my restricted-usernames list.
3. Set the purge threshold and purge rate
   In your denyhosts,cfg file, set PURGE_DENY to something reasonable, 1 – 2 weeks perhaps. Otherwise, your hosts.deny might good huge.
   Then, set the PURGE_THRESHOLD to 2 -3. This means that while entries older than your PURGE_DENY will be removed from the deny list, if it occurs more than your PURGE_THRESHOLD, they will not be purged. This is more likely to stop the entries most often attempted.
4. Rotate log files
   Assuming you have logrotate installed (and why don’t you?), the FAQ has a great example file for adding a rotate entry for DenyHosts.
5. Sync with central DenyHosts database
   One feature which really makes DenyHosts shine is the ability to share known rogue agents among DenyHosts instances. It is off by default, but to turn it on, edit denyhosts.cfg in your working dir. To enable synchronization, simply uncomment SYNC_SERVER. The value it is set to should be correct. By default, once synchronization is one, every hour the daemon will check with the server specified. It will upload hosts that you have denied, and download hosts that at least 3 others have denied. If you wish, you can tweak the timing of this process, just to upload, the threshold for downloading, etc.
   For more details, see the FAQ.

After these changes are made, be sure to restart DenyHosts via

.