Pixelated Ninja

As with all good intentions, sometimes other projects come along. I will still be posting here, but for now you can see my newest project.

FirstGenGamers

Feel free to join us there if you are so inclined.

Hello all, I’m still around.

Just dropping a note to let you all know I have a few new things in the pipeline. I’ll hopefully have them in a post soon.

• Linux Bluetooth Tricks
• I’ve been working on a Perl application that uses the linux Bluez system to run certain applications once you get in range. Currently only checks your mail and displays on screen how many you have or speaks it outloud. I’m working on a modular version right now that will let you do *whatever* you want.
• Small script for the G15 Keyboard that will allow other people to display messages on your keyboard via a web form.

Till next time.

This is going to be a quick post. First I’m going to show you a realtime graph from my machine graphing out ssh brute-force attempts. Then I’m going to give you a few tips to help keep your machine safe. I’m not going to go horribly in-depth on this one unless I get some requests to do so.

Daily:

Yearly:

That should at least give you an idea of how often people are probing my system alone. I see on average 2 attempts spanning 50-60 combinations of user/pass a day.

You’ll notice that most of the attempts against my machine are for completely invalid users, only rarely do they seem to hit any real user accounts on it. Its not even that those accounts actually do not exist, its more that they’re not in my AllowedUsers field (read below).

Locking Down

Most of these tips involve editing your /etc/ssh/sshd_conf file. One of the biggest improvements you can do is turn off root logins via ssh. I think this has become pretty common practice now, but just incase make sure PermitRootLogin is set to no or commented out in your config.

Next make sure you specify who can log in via AllowUsers. If you explicity tell it who can log in and who can’t you’re less likely to fall prey to a default password set on some random service that needs a new system user.

This definatly is NOT a definative list of ways to secure your system against ssh attacks. This is only a few minute config change that will definatly help secure it.

I’m going to take a time out of my normal posts, to post up an open letter to EB Games. Its still tech related and loosely related to linux as I would have installed it on one of these. So in place temporarily of that howto, you get this now. I’ll get back to working on the next article after I’ve blown off some steam.

—————

[Clipped out]

—————

Update:  I got a call from the district manager in my area, 2 days after this post.  He appologized and made arrangements for a PS3 to be held for me.  I consider the matter closed and will do buisness again with them after a quick response like that.  If anyone has problems with and individual store, I suggest you do write an email to their helpdesk as it seems to work.

Recently my old fileserver died. I could rebuild it.. Make it better, stronger, faster. So I got a new machine along with two 500GB drives. I’m going to break this up into a few parts first the underlying filesystems and my reasoning behind it and the second part will be the configuation of samba with virus checking enabled (via Samba VFS).

On my machine I only put in the two drives due to space issues in the machine. So to make the most out this space I’m going to LVM the drives together so that I can make one samba share that uses the whole two drives with the exception of the OS. To do this, I do my OS install as usual (be sure to add LVM into the kernel). Be sure to make the majority of the drive partitioned as LVM (make the partition of type 8e). For an example of what I mean here is my fdisk -l output.

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 1 9 72261 83 Linux
/dev/sda2 10 71 498015 82 Linux swap / Solaris
/dev/sda3 72 1288 9775552+ 83 Linux
/dev/sda4 1289 60801 478038172+ 8e Linux LVM

The mount points end up being:

/dev/sda1 : /boot (70MB)
/dev/sda2 : SWAP (512MB)
/dev/sda3 : / (10GB)
/dev/sda4 : LVM partition (REST)

/dev/sdb only has 1 partition of type LVM spanning the whole disk.

First thing to setup the LVM is to prepare the partitions:

root@host # pvcreate /dev/sda4 /dev/sdb1

Now its time to create a volume group. A volume group is just the two drives combined into one physical device.

root@host # vgcreate vg /dev/sda4
root@host # vgextend vg /dev/sdb1

You don’t have to call the volume group vg as I did above, I just wanted to use a generic name for it. Also you’ll notice I used vgextend to add the second drive into the volume group. Up to now, you’ve created a volume group, thats basically equivilent to /dev/sdx you still will need to partition that out. However you won’t be using fdisk on it, its not a normal drive so fdisk wouldn’t know how to handle it anyways. You will need to use lvcreate, I want mine to use the full size of the volume group so I need to know how big it is, easiest way to do this is to look for the “Total PE” field when you run vgdisplay.

root@host # vgdisplay vg | grep “Total PE”
Total PE 235942
root@host # lvcreate -l 235942 -ncontent vg

The -n flag specifies what to name the logical volume. You will need to know that to make the filesystem on that new device and to mount it. When making the filesystem you should be able to do something along the lines of:

root@host # mke2fs -j /dev/vg/content

You can mount the device now using that same dev entry. In this case I now have it mounted in /content df says it is 922GB in size. Perfect. I should probably point out why I went with LVM instead of raid. With raid striping across the two drives if one drive started to fail, it would be more difficult to save the files. The raid dies, all of the data is gone. With LVM if one of the drives start to go bad, you just connect the new drive to it and migrate the data over the new drive then remove the old one from the volume group.

Thats it for now. I’ll update with the Samba+Antivirus part once I get the bugs worked out of it.

This is something I’ve been doing for awhile now. When you have accounts on literally a thousand plus machines, its kind of a must. I never want to sit there and type my password multiple times so I let ssh-agent do it, from then on I just ssh to the machine and it automatically logs me in.

Its fairly simple to do. First you need to generate a key that you will be using.

user@host ~ $ ssh-keygen -t rsa

It will ask you where to save it, the default should be okay as long as its not overwriting another file in your ~/.ssh directory. After that it will ask for a passphrase. You can leave that blank if you want, but I don’t advise it. Leaving it blank will allow anyone who gets your private key (in this case id_rsa) to ssh to any machine you have your public key on with no password. Its easy to find out what machines you ssh into just by looking in your ~/.ssh/know_hosts file. Game over man, game over!

So now you have your public and private keys. Upload your public key to a machine you will be ssh-ing into. You can just put it in your home directory for right now. Now if you don’t have a ~/.ssh/authorized_keys file yet, just move you public key to it. If you do you can just append your current key to it by doing something like:

user@host ~ $ cat id_rsa.pub >> ~/.ssh/authorized_keys

SSH is picky about key ownership and permissions so make sure to chmod 600 authorized_keys.

Great you’ve configured both machines now. If you try sshing to that machine you will see something along the lines of “Enter passphrase for key ‘/home/user/.ssh/id_rsa’”, remember that is the passphrase for the KEY not the password for the HOST. Once you enter that it will log you into the remote machine.

Here’s were the magic happens now, I told you I didn’t have to enter a password on all of my remote machiens. Thats because I’m using ssh-agent to take care of entering my passphrase for me. ssh-agent will run in the background once you start it. Don’t just run it normally however, ssh-agent will output a bunch of variables that you need to set, so instead run it like this:

user@host ~ $ eval `ssh-agent`

For the record those are backticks not single quotes. Now that you have ssh-agent running you need to add your key to it with ssh-add. After running that it will ask you for your passphrase, enter it and your good to go.

On my desktop I added the following to ~/.fluxbox/apps to start ssh agent when fluxbox loads.

[startup] eval `ssh-agent`

Then when I need to ssh I add the key by hand with ssh-add and remove it when I’m done with “ssh-add -d”. That should be all you need to get started with ssh-agent and passphrases.

Yay atomation

After using the dd utility on a disk you will need to update the partition table in the kernel before mounting it. Normally a reboot is sufficient. If you don’t want wait for a reboot you can use the blockdev application to force a reread of the partition table. Its a simple matter of doing:

root@host ~ # blockdev –rereadpt /dev/{device}

Happy Partitioning!

Do you know what bothers me? Monotony. I hate doing the same thing over and over. Having to repeat the same steps is just a dirty way to do things, there’s got to be a more elegant way. So what the fsck does this have to do with FUSE? You’ll find out in due time, first let me tell you what brought this about.

While working on a site, I started getting annoyed by constantly ftping a slight change in my code to test it. Sure I could have setup a local test-bed, or ssh’d in and edited it with vim or emacs. One: I didn’t want to setup a test bed for this one site. Two: I prefer Nedit when working on code. So in this case it was just keep ftping over and over and over and …

Enter FUSE (see, I told you I would get on topic sooner or later, how dare you doubt me). FUSE simply is a userspace filesystem, meaning someone can write their own filesystem without having to write complex kernel code. So using the FUSE module and SSHFS I was able to mount a directory on my remote machine localy and read/write to it in near real time. No more FTP and no more monotony, and I get to use my editor of choice. Score!
FUSE was officially merged into kernel 2.6.14 and up, this quick howto deals with a 2.6.19 kernel, if you’re kernel is older then 2.6.14, it may be time to update and compile a new one or read the official docs on their site.

Lets get started.

In my case I didn’t want to have to recompile the whole kernel and reboot after reconfiguring everything. I just compiled FUSE as a module and loaded it right afterwards. So first, make sure you have /usr/src/linux and that its symlinked to the directory that has the sources for the running kernel.

beowulf ~ # uname -a
Linux beowulf 2.6.16.19 #3 SMP PREEMPT Wed Aug 16 14:37:13 MST 2006 x86_64 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
beowulf ~ # ls -alh /usr/src/linux
lrwxrwxrwx 1 root root 15 Aug 15 18:24 /usr/src/linux -> /usr/src/linux-2.6.16.19

As long as those two match up, you’re good to go. If they didn’t either adjust your symlinks or get a new kernel.

Now we need to actually compile the module. cd to /usr/src/linux and run ‘make menuconfig’ as root. First make sure you have loadable module support.

Loadable module support  --->
[*] Enable loadable module support
[*]   Module unloading
[*]     Forced module unloading

If you don’t have that (you really should have it), you’re going to have to recompile the whole thing anyways. See your distro’s documentation on that.

Now add the FUSE module.

File systems  --->
<M> Filesystem in Userspace support

Now go ahead and exit out. As root:

beowulf linux # make modules && make modules_install

You’ve now compiled and installed the FUSE kernel module. Time to load it into the running kernel:

beowulf linux # modprobe fuse

You can make sure it loaded by doing:

beowulf linux # lsmod | grep fuse
fuse 35352 0

Now go get whatever actuall filesystem you want run with fuse from HERE.

The rest of this deals specifically with the SSHFS filesystem. Download and compile it. It may be in whatever package system your distro uses. I use Gentoo, so I just emerged it. Installing from source is easy however.

> ./configure
> make
> make install (as root)

Now all thats left is to mount your ssh filesystem.

sshfs examplehost.net:/path/to/remote/directory /path/to/local/directory

Unmounting is just as easy.

fusermount -u /path/to/local/directory

If you happen to lose your internet connection after you mount it, and you get an error similar to “Endpoint not connected” you will need to add a -z to fusermount to unmount it.

Once you have it mounted, just cd into your local directory and modify files as use see fit.

See you next time, same Bat blog, same Bat time.

Welcome to the Pixelated Ninja. By trade I work with computers for a living, specializing in the Linux OS. The purpose of this site is to track my day to day Linux use, and putting this information, how-tos, tutorials, and what-not out for public consumption.

While Linux is my specialty, I do not hold the same for this site. I will be posting related topics such as connectivity, networking, and even random web work.

I have abosultly no formal training. I don’t pretend to be an expert at all, I am however very knowledage. I’ll try to answer any random questions if anyone has any, from servers to desktops. Best way to reach me is to go to my contact page.