Talk:Setting up a Server

Rename / Move discussion

I agree with merging this page with Home server. This page is for a public server accessible from the internet, Home server is for a private server accessible from within the owner's LAN. I think the articles can be seamlessly integrated as the information they provide is mostly the same. --Eva-02 (talk) 21:17, 13 February 2014 (EST)

I have a NAS4Free server, and I have my own VPS. They bear almost zero resemblance to each other in terms of how they are set up. In fact, I think the only thing they have in common is a http server (NAS4Free is mostly configured through a web interface). You could consolidate it into one ginormous page, I guess, but to what end? Toynbeeidea (talk) 21:52, 13 February 2014 (EST)

I propose splitting this article. The stub at the bottom labeled "Setting Up Email and web server, the EASY way" should be merged with Home server and the rest of the article should be pushed into its own article on "server security". The vast majority of this article is simply hardening for dumbos. --Durandal (talk) 09:42, 16 February 2014 (EST)

Eh... I guess you could, technically, set up email on a home server, except that most (amerikkkan) ISPs would block the ever-loving shit out of it no matter how you set it up. But again, that's an internet-facing service. I guess my point is, I think of a "home server" as a "file server." You're gonna use that to stream your movie files to your xbawks and shit, not to serve up web pages to the general public. My guess is that people are probably way more interested in that. Toynbeeidea (talk) 07:54, 17 February 2014 (EST)

I think this article should just be renamed "Securing a server" and then a link directing to this page should be added to the warning message on Home server. The Home Server page has plenty of info on setting up a server. --Moistcake (talk)

I think I merged everything relevant from Home server to here.--Thelismor (talk) 07:53, 1 April 2015 (EDT)

New sources

Ars Technica has started a series on setting up an email server. They recommend iRedMail. I haven't had time to do a lot of writing lately, so I haven't been working on any of the content on this page, sorry. Toynbeeidea (talk) 16:37, 17 February 2014 (EST)

This has also been my long delayed thing on my server. I'll take a read and attempt it soon to see if it's viable. I would probably personally also try Postfix + Dovecot again though. I'm not going to setup PHP stuff like roundcubemail though. I'll tell how it goes. Thanks for the link. WubTheCaptain (talk) 19:46, 17 February 2014 (EST)

Clarification for securing shell

Because I'm dumb I didn't realize there already were 2 server articles, so I started writing my own. I'm merging everything into this page now, but I'm not sure what to do about the SSH part.

This guide seems to be more thorough than mine (see end of this message) but it is not as well explained. Can someone clarify?

• On my system, my account does not appear in sudoers at all, even though I can sudo (Ubuntu 14.04).
• Creating .ssh - wouldn't mkdir ~/.ssh be better (less risk of typos)?
• What are the options added to sshd_config?
• Is there any point to filtering by username?

Disable password login for SSH

First you need to generate keys for authenticating yourself.

openssh-server will look for keys under ~/.ssh. On your server, run:

mkdir ~/.ssh
chmod 700 ~/.ssh

Generate a pair of 2048-bit RSA keys:

ssh-keygen -t rsa

This will ask you for a file to save the key in and walk you through the process:

Generating public/private rsa key pair.
Enter file in which to save the key (/home/b/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/b/.ssh/id_rsa.
Your public key has been saved in /home/b/.ssh/id_rsa.pub.

Use a good passphrase that you can remember easily and don't mind typing a lot. You will use this passphrase everytime you SSH into your server.

Now you need to record the public key in the authorized key store. Make a backup, then copy the public key:

cp authorized_keys authorized_keys_Backup
cat id_rsa.pub >> authorized_keys

There should be one RSA key per line in the authorized_keys.

Now take the private key (id_rsa without .pub) and put it on every machine that should be able to connect by SSH. After that's done, you need to disable password authentication. First open sshd_config:

sudo nano /etc/sshd_config

Make the following changes:

• Change PasswordAuthentication yes and to PasswordAuthentication no.
• Change RSAAuthentication no to RSAAuthentication no.

Save with Ctrl+X, Y, Enter.

You will no longer be able to use your Linux user account password to login with SSH. You'll need to point your SSH client (ie. PuTTY, openssh-client, etc) to the private key, and you will still need to enter a password. This password is to unlock your private key.

If your client machine is ever stolen, the attacker will obtain your key. They will not be able to login, because they don't know the passphrase of the key. However, they can now try to brute force your password, so you should make a new pair of keys (by repeating this process except for the sshd_config part), delete the old public key from authorized_keys and switch to the new one.

Random hackers on the internet will fail because the server will refuse connection attempts unless they are trying to use a key.

--Thelismor (talk) 07:53, 1 April 2015 (EDT)