“Don’t run as root” is an oft-repeated mantra of *nix security. While I agree 100%, it’s not as big on the desktop as some would think. I’d like to point out why here. I still believe you shouldn’t login as root, but I also believe that it’s up to each user to make their own decision.

Think about the data on your computer. What matters to you? E-Mail? Documents? Images? Most of us have things like family photos, financial records, personal communications, saved passwords, or other sensitive or irreplaceable data. This is what we want to protect. When I backup my desktop, I backup my home directory. I don’t backup my OS install, software, or anything else that is not private or difficult to replace. Think of this as the “important stuff.”

So, let’s talk about the important stuff. What users have access to YOUR important stuff? Most likely, your own user, and the root user. So, great, not running as root eliminates one of the possible users that can access your file. So what user do you run as? Your own user. So it’s pretty obvious that not running as root doesn’t restrict access to the important stuff.

Need proof that your data is no safer under your own user? Think about running “rm -rf /” as root or as your own user. What happens to your data either way? It’s gone. Don’t run this, just think about it.

So what do you gain by not running as root? Well, your system is a lot less likely to be the victim of an ongoing compromise. As root, an attacker can modify your operating system to their liking. Think that’s not much? Guess what: your ssh client now sends the username, host, and password for any system you connect to to a server in China. Or maybe new files you create are uploaded to an anonymous file-sharing site on the internet. Perhaps every key you touch is recorded to grab usernames, passwords, credit card numbers, and your most personal conversations. Or maybe an attacker uses your computer as a middle man for downloading child pornography. That will be fun to explain to the FBI.

So, obviously some things need to run as root: system configuration tools, for example. However, running these using sudo limits your exposure to just these utilities, rather than the thousands (millions?) of lines of code in a full desktop environment.

In short, if you want to run as root on your desktop, go for it. But know the risks, and know the consequences. On the other hand, don’t chant “don’t login as root” as if it’s a magic bullet for security.

It’s a well-documented fact that RAM in modern computers is susceptible to occasional random bit flips due to various sources of noise, most commonly high-energy cosmic rays. By some estimates, you can even expect error rates as high as one error per 4GB of RAM per day! Many servers these days have ECC RAM, which uses extra bits to store error-correcting codes that let them correct most bit errors, but ECC RAM is still fairly rare in desktops, and unheard-of in laptops.

Makes me want to build my next desktop with ECC RAM.  Of course, that requires a motherboard that supports it, among other things.  When you’re using encryption, a single bit error can result in the inability to decrypt an entire file.  I wonder what steps could be taken to mitigate those sort of issues.

I’ll probably lean towards working on an LPIC-1 certification next.

On March 2nd, I will be starting a new job as an IT System Support Specialist III at Kennesaw State University.  Typical of a government job, the title is rather meaningless.  To be specific, I will be supporting a variety of Linux and Mac OS X servers for the university and the platforms running on them (Drupal, Moodle, and other technologies.)  The production servers are RHEL and the development is on CentOS.

Of course, every good turn comes with a down turn.  On Wednesday, I went to my doctor because of a little bit of abdominal pain for 2 days.  Because of the location of the pain, and a bit of an elevated white blood cell count, he sent me over to the ER to get an abdominal CT.  Turns out that my appendix was “slightly inflamed”.  Long story short, about 10PM that night I was in the OR having my appendix removed.  It may be a common procedure, but the pain is still pretty decent.  Hopefully it will be gone before I have to start the new job.  And hopefully I won’t have to do heavy lifting in the first couple of weeks of my new job. 

My desktop, on the other hand, I keep squeaky clean.  On the other hand, I sometimes have related files on my laptop and desktop… so even more filesystem mayhem.

So I think I need a good way to manage my laptop files.  First off, more self discipline.    Secondly, I’m thinking of a small utility to merge files between two systems.  Perhaps some sort of bi-directional rsync based on modified dates?  Maybe also a method for mapping particular files/directories on one system to the other.  From the days of Windows 9x, I remember something like Windows Briefcase (if that’s what it was called) and it now seems like a decent idea.  Anyone know of this?  If not, maybe it’s time to learn some Glade and pyGTK.

Slides are available here: SSH & GPG. They don’t show everything, as a lot of it was Demo and Q&A, documented below.

This is Part 1 of a two part series.  I got far more questions about the OpenSSH content, so I’ll be focusing on that here.  I’ll add GnuPG content shortly, time permitting.

SSH Basics

Connect to a remote server via ssh:

ssh USERNAME@HOSTNAME [Optional command to execute]

To generate a SSH keypair and transfer it to remote server for authentication:

ssh-keygen -t rsa && ssh-copy-id HOSTNAME

You can then send it to more HOSTNAMEs just be repeating the ssh-copy-id HOSTNAME step.

Setting up a Config File

By creating a file .ssh/config, you can permanently set certain options.  Each server is represented by a Host stanza, and the value of this is how you refer to the server.  For example:

Host router1
    HostName router1.example.com
    Port 2222
    Username admin

Performing “ssh router1″ with this config file is equivalent to “ssh admin@router1.example.com -p2222″, saving a lot of typing for those servers you connect to all the time!  In the advanced section below, I’ll demonstrate both the command-line option and the config file option.

Advanced SSH Features

The following sections demonstrate some of the more advanced ways SSH can help secure your communications and save you time.

TCP Connection Tunneling

If you want to create an encrypted tunnel out of your current network for a service, you can use the -L SSH option.  It takes -L localport:remotehost:remoteport.  You then connect your application to localhost:localport, and it acts like you’re connecting from your SSH server!  Great for getting around/behind firewalls.

ssh -L 25:mailserver:25 user@host
ssh -L 1080:socksserver:1080 user@host

In .ssh/config:

LocalForward localport remotehost:remoteport

If you want, you can also have SSH act like a SOCKS server, and all communications between your client and this virtual socks server will be encrypted!  Set up your client application to connect to a SOCKS 4/5 proxy on localhost, port 8080, and then connect to an SSH server via:

ssh -D 8080 user@host

In .ssh/config:

DynamicForward 8080

Multiple SSH sessions in one connection

You can use a single TCP connection for multiple SSH sessions to the same server.  This reduces latency in starting the 2nd and further connections, and does not require additional authentications.  This is very useful when doing frequent operations over SSH.  This is only really useful when specified in the .ssh/config file as this:

ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

Using ssh in a pipe.

It can be useful to send data from one side to another via an ssh connection.  Perhaps there is some filter only installed on the remote system, or you wish to copy over a large directory structure but rsync is absent on the remote system.

# copy dir1 to dir2 on target without rsync, as one command:
tar cz dir1 | ssh target tar xz -C dir2
# use hexdump on the remote system
cat somefile | ssh target hexdump

Store your SSH key in memory for your session.

You can store the SSH key in memory, already decrypted, to avoid having to put in your passphrase repeatedly.  This allows it to stay encrypted on disk and protect your key from tampering.

eval `ssh-agent`
ssh-add

You can also use Keychain from the Gentoo project (though now available in most distributions) to maintain a per-reboot ssh-agent session.  This is very useful on desktops as it is available to all terminals and applications rather than a single shell session.  Full documentation for keychain is available at: http://www.gentoo.org/proj/en/keychain/

Conclusion

If you have any questions or feel anything needs a clarification, leave a comment and I’ll be happy to update with more content!

1. RedHat 9. For that matter, you should not install any of the “classic” RedHats. They’re old and outdated. If you want commercially supported, look at RHEL. For free RedHat-like distributions, look at CentOS (Server) and Fedora Core (Workstation). If you run a RedHat 9 server that faces the internet, there is a good chance you will get rooted. It is NOT supported for security or otherwise.
2. Telnetd. [Edit: several people have pointed out that I did not make it clear if I meant the server or the client.  The telnet client is quite useful, it is the server that introduces many security concerns.] Telnet is unencrypted and unsecure. Would you send your credit card number over an unencrypted link? Then why send your passwords? SSH can do everything Telnet can, and more. SSH can do file transfers, encrypt other connections, compress your data stream, and allow you to connect without typing a password. Oh, and there are SSH clients for just about every system on earth, so no worries about incompatibilities.
3. rsh, rlogin, etc. The authentication mechanisms in rsh and rlogin can easily be defeated. Oh, and they use plaintext too, so everything that applies to Telnet applies here as well.

I can think of several more items, but these are the biggest for security. And while you’re configuring the SSH server, don’t forget to turn root logins off with “PermitRootLogin no”.

Community colocation projects (CCPs) are a non-profit datacenter for non-profity entities and individuals. This would be a great opportunity for an advancement of Open source projects and for the community in Atlanta and the metro area. Atlanta is the center of high-tech development for the Southeastern United States, and as such, should become a leader in the Open Source arena.

Thoughts and comments are appreciated.

In order to manage this flood of multimedia, I have a jfs filesystem mounted as /multimedia. Today I wanted to import about 10GB of music that “escaped” iTunes on my windows laptop. In doing so, I completely filled my existing /multimedia partition. Ordinarily, that would be a problem, wouldn’t it? Not with LVM

LVM, or Logical Volume Management, divides hard drive space up into a number of chunks (extents) that can be allocated (on-demand) to given virtual partition. The only downside is that the filesystem on the partition must support resizing. Most filesystems (well, most Linux filesystems) take to resizing larger very well. Some do not shrink as well.

So, to give myself another 20G of multimedia was a simple:

umount /multimedia
lvextend -L220G /dev/MainVG/VideoLV
mount -o resize /multimedia

Imagine trying to expand space on a 200G partition without LVM.  I think most people would have just symlinked in more data, or split the data onto two partitions.