FJ

florianjacob.de_

This is the first post of my emerging server guide. The guide will show you how to reproduce my server setup, what decisions I made and why I made them (in case it’s not just based on personal taste, or, well, maybe even then ;) ). This should serve as a reference for you, just because it seemed right for me doesn’t mean it’s right for you, too. Don’t shut down your brain when following this. Read my comments, and the comments in the config files. Still, this guide is written for, well, maybe not Linux beginners but for beginners starting to be intermediates on the command line, who see themselves confronted with managing a system solely by the command line. If you don’t understand something, read about it on the web! For basic stuff, I’ll only tell you what to do, but in case commands or terms I use are new to you, stop reading and learn about them. Try to understand what you actually do there, if you don’t you’ll end up wit a system you can’t handle. Chances are you’ll get hacked and held accountable for all that spam sent out from your server. You’re warned.

Before you get any service running, you need a solid foundation to work with. This entry covers the basics of how to set up your working environment on the server, and some tricks & hints to ease your future work.

Let’s assume you just installed Debian Squeeze on your server machine or just got the root password from your provider and logged in.. Do you feel the power? ;) First thing is to make sure the door you just entered through gets closed, so no one can follow you.

# Change your root password! And make sure you remember it,
# resetting the root password is unnecessary work. You've better things to do!
passwd

# Change the sources.list at the bottom to include squeeze-backports (for a newer tmux version)
vi /etc/apt/sources.list
=>
# backports for tmux
deb http://backports.debian.org/debian-backports squeeze-backports main
=>
# Debian Squeeze is quite old now. (Maybe not in Debian scales..)
# A lot of security holes in the shipped software got fixed by then,
# so upgrading will take time, but still, as always, get all upgrades immediately.
aptitude update
aptitude upgrade

Well, so far it was trivial. Next step is to install the tools you need.

vim

Well, my favourite editor. If you never used any editor on the terminal, you might want to give nano or pico a try, and read http://www.rudism.com/s/vimcreep .

zsh (seperate post)

My favourite shell. If you just used bash (the standard shell) so far, just follow what I write here and you’ll end up with a shell with amazing autocompletion features.

git

Last point in the favourites line-up, git is the distributed version control system I use most. etckeeper works with mercurial and bazaar, too, so you can install whatever you like.

htop

This is the terminal equivalent of your graphical process monitor on your desktop. Start it up, and you’ll see the cpu and memory usage of the machine and all running processes sorted by their cpu usage.

tmux (seperate post)

Desktop terminal emulators usually have the feature of tabbed terminals. tmux does something similar on the server side, it’s a terminal window manager where you can create, switch and close windows, and especially leave them open and running when you disconnect from the server. You should try to work inside a tmux window on the server, so when you get interrupted, you can always just detach the window and log off while e.g. upgrades, compiles, backups or other long-lasting operations still keep running.

etckeeper (seperate post)

etckeeper is a tool to get all of your config files beneath /etc under a version control repository. If you use it from the beginning, you can always get back to any revision of your config files in case something goes wrong, and it even creates an automatic revision if you install something with aptitude.

Oh, and by the way, I like to make notes on paper or in a text file to record what and how I configure a server (actually I do that for desktop / laptop installations, too) to keep track of the problems I ran into and how one can solve them. Very handy if you have to reproduce your setup after a fresh install, and as you might have guessed now, this guide is actually based on the notes I made for the latest server. ;)

From now on, when I put something in <pointy brackets>, that’s the stuff you have to replace with your own parameters.

# Install your favourite tools to work  with the server
aptitude install vim zsh git htop etckeeper
aptitude -t squeeze-backports install tmux
# One shouldn't be logged in and work as root if one doesn't need to. Create a normal user for yourself, later we'll even forbid root logins.
adduser <username>
logout

# reconnect as the newly-created user
ssh <username>@<host>
# Now we start to secure the ssh daemon. Open the sshd config file:
su
vim /etc/ssh/sshd_config
# Find the line saying PermitRootLogin Yes, and change it to
PermitRootLogin No
# For now, you should use your own random port for ssh, choose a number between 10000 and 65000
# You can leave it at 22 though, in case you want to use ss(l)h later on. (will be a separate post again. ;) )
Port <port>
# Close your editor again, and restart the ssh server. Hope that everything you entered was right.
service ssh restart

# You installed etckeeper already. We just made the first change to a config file in etc, so we
# commit the changes and create a new revision.
# There'll be a seperate post on that, too.
git add /etc/ssh
git commit -m "Changed ssh port and prohibited root login."
logout


# On your local machine again, you can create a config file for ssh.
# This will enable auto completion for ssh hosts on zsh,
# and ssh <hostname> will be enough to connect in the future.
vim ~/.ssh/config
# Add these lines
Host <host>
    User <username>
    Port <port>
# and close the editor again

# Generate a new rsa key pair in ~/.ssh/
# id_rsa is your private key. If you don't enter a passphrase while generating the key,
# everybody who has this key file can login to every server you allowed it to. No passphrase
# makes sense for automatic login in scripts, but for your personal use, you should enter one.
# id_rsa.pub is your public key file, this can be safely shared with anybody.
ssh-keygen -t rsa

# This copies your public key file as an authorized key to the specified machine. Afterwards,
# you can log in using the private key.
ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<host>

# Try to log in, you should be asked to enter the passphrase for your key instead of the password.
ssh <username>@<host>
logout

#!/bin/sh

export SSH_ASKPASS=/usr/bin/ksshaskpass
ssh-add </dev/null

# console tip:
# You can find out the absolute path of any binary, e.g. ksshaskpass, with
which ksshaskpass