{"id":1540,"date":"2016-11-26T22:20:49","date_gmt":"2016-11-27T02:20:49","guid":{"rendered":"https:\/\/lowtek.ca\/roo\/?p=1540"},"modified":"2017-12-06T11:26:41","modified_gmt":"2017-12-06T15:26:41","slug":"server-upgrade-part-2-basic-os-setup","status":"publish","type":"post","link":"https:\/\/lowtek.ca\/roo\/2016\/server-upgrade-part-2-basic-os-setup\/","title":{"rendered":"Server Upgrade: Part 2 – Basic OS setup"},"content":{"rendered":"

At this point I’ve got the hardware setup and running, but it’s a very basic install. This post is inspired by a post<\/a> I came across some time ago that I felt gave some good advice. I’ll walk through the steps I took while following that article.<\/p>\n

Starting with a clean Ubuntu 16.04.1 server install.<\/p>\n

1st login<\/strong><\/p>\n

$ sudo apt-get update\r\n$ sudo apt-get upgrade\r\n$ sudo apt-get install fail2ban\r\n$ mkdir .ssh\r\n$ chmod 700 .ssh<\/pre>\n
Fail2ban<\/a>\u00a0is a must have security feature, blocking traffic when it detects repeated failed attempts to access your system.<\/p>\n
Now we want to make some ssh keys following the Ubuntu documentation<\/a>. One key question is how big a key should we be using for reasonable security? I think the answer is 4096 bits<\/a>.<\/p>\n
cd .ssh\r\nssh-keygen -t rsa -b 4096\r\ncp id_rsa.pub authorized_keys\r\nchmod 400 authorized_keys<\/pre>\n
Why create a key on the new machine? I have the opinion that unique ssh keys for unique machines is a good idea, and the ssh config file<\/a> makes is really simple to manage multiple keys on your main machine (laptop).<\/p>\n
Should you make use of a passphrase when creating your ssh key? If you really care about security, yes – you should. Otherwise anyone who manages to get their hands on your key immediately has access to everything. There is a small usability trade-off, since you need to provide that pass phrase (password) every time you want to use the key.<\/p>\n
The ssh config file (not on the host, but on your laptop) will look like this:<\/p>\n
$ cat config\r\nHost\u00a0newmachine\r\nHostname newmachine.mydomain.ca\r\nIdentityFile ~\/.ssh\/newmachine.key<\/pre>\n
Assuming you’ve copied the private key (id_rsa) from the new server you’re setting up to the laptop, make sure to chmod 600 that key file too.<\/p>\n
Now we should be able to ssh into the new server from our laptop. Hooray, it works!<\/p>\n
Time to lock down ssh so key based logins are the only way<\/p>\n
$ vi\u00a0\/etc\/ssh\/sshd_config\r\n\r\n# Change to no to disable tunnelled clear text passwords\r\nPasswordAuthentication no<\/pre>\n
You might want to have a shell logged in to the machine while you do this, so you can verify that things are cool AND fix stuff if there is a problem. Otherwise you’re locked out.<\/p>\n
Time for a firewall<\/strong>, we’re going to use ufw because it’s simple and does the IPTables<\/a> setup for us.<\/p>\n
$ sudo ufw allow 22\r\n$ sudo ufw allow 80\r\n$ sudo ufw allow 443\r\n$ sudo ufw enable<\/pre>\n
We’re letting ssh, http and https protocols, and that’s it. We’re not yet running a web server, but we will at one point.<\/p>\n
Now let’s reboot and see how things are doing, if we can’t login — we really broke stuff. In my case, everything was still working just fine. If you did break things, go get the USB install for Ubuntu and boot a live version on the machine and use root access there to fix the configuration files to let you get back in — or just re-install and start over.<\/p>\n
When I did the original install, I opted to not do automatic security updates. This was\u00a0a mistake so I’ll fix that now.<\/p>\n
$ vi \/etc\/apt\/apt.conf.d\/10periodic\r\n\r\n# Change things to look like below\r\nAPT::Periodic::Update-Package-Lists \"1\";\r\nAPT::Periodic::Download-Upgradeable-Packages \"1\";\r\nAPT::Periodic::AutocleanInterval \"7\";\r\nAPT::Periodic::Unattended-Upgrade \"1\";<\/pre>\n
Again, from the post I’m sort of following along – they recommend logwatch<\/a>, something I haven’t used previously. Having run with it for a while now, I’ve grown to like the level of detail it pulls together into a daily email.<\/p>\n
$ sudo apt-get install logwatch<\/pre>\n
Now the logwatch installation triggered a postfix install and configuration. This is probably useful for my host to have email capability, but really I want to host my main mail system inside a docker container. Hopefully this won’t cause me grief in the future as I build out the set of containers that will run email etc.<\/p>\n
I just picked the default postfix ‘internet’ install and it appears to have done the right thing to allow the new server to send email to lowtek.ca, so that’s positive. Again, my concern is when this new machine starts hosting the lowtek.ca email inside a docker container, how will all of that work? An issue I’ll certainly cover in a future post.<\/p>\n
$ vi\u00a0\/etc\/cron.daily\/00logwatch\r\n\r\n# execute\r\n\/usr\/sbin\/logwatch --output mail --mailto myid@lowtek.ca --detail high<\/pre>\n
 <\/p>\n
Almost done.<\/strong><\/p>\n
At this point, things are pretty good, but..<\/p>\n
Welcome to Ubuntu 16.04.1 LTS (GNU\/Linux 4.4.0-31-generic x86_64)\r\n\r\n * Documentation:  https:\/\/help.ubuntu.com\r\n * Management:     https:\/\/landscape.canonical.com\r\n * Support:        https:\/\/ubuntu.com\/advantage\r\n\r\n10 packages can be updated.\r\n7 updates are security updates.\r\n\r\n\r\n$ sudo apt-get upgrade\r\n[sudo] password for roo: \r\nReading package lists... Done\r\nBuilding dependency tree       \r\nReading state information... Done\r\nCalculating upgrade... Done\r\nThe following packages have been kept back:\r\n  linux-generic linux-headers-generic linux-image-generic snapd ubuntu-core-launcher\r\n0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.\r\n<\/pre>\n
I’m concerned by the 10 packages that aren’t being automatically upgraded. It turns out that this is easy to fix with a dist-upgrade.<\/p>\n
$ sudo apt-get dist-upgrade\r\nReading package lists... Done\r\nBuilding dependency tree       \r\nReading state information... Done\r\nCalculating upgrade... Done\r\nThe following NEW packages will be installed:\r\n  linux-headers-4.4.0-47 linux-headers-4.4.0-47-generic linux-image-4.4.0-47-generic\r\n  linux-image-extra-4.4.0-47-generic snap-confine\r\nThe following packages will be upgraded:\r\n  linux-generic linux-headers-generic linux-image-generic snapd ubuntu-core-launcher\r\n5 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.\r\nNeed to get 74.8 MB of archives.\r\nAfter this operation, 306 MB of additional disk space will be used.\r\nDo you want to continue? [Y\/n]<\/pre>\n
And of course, I continued and got all of the latst upgrades to the 16.04 tree. If you’re observant, you’ll notice that 16.04 is still back on an older kernel (4.4) which is fine, this is the LTS release.<\/p>\n
One more\u00a0reboot… then we see<\/p>\n
Welcome to Ubuntu 16.04.1 LTS (GNU\/Linux 4.4.0-47-generic x86_64)\r\n\r\n * Documentation:  https:\/\/help.ubuntu.com\r\n * Management:     https:\/\/landscape.canonical.com\r\n * Support:        https:\/\/ubuntu.com\/advantage\r\n\r\n0 packages can be updated.\r\n0 updates are security updates.\r\n<\/pre>\n
excellent. We’re current, and with the automatic updates we’ll get security patches with no additional effort. Non security patches will not install automatically, so from time to time we’ll still need to manually pull down patches.<\/p>\n","protected":false},"excerpt":{"rendered":"
At this point I’ve got the hardware setup and running, but it’s a very basic install. This post is inspired by a post I came across some time ago that I felt gave some good advice. I’ll walk through the steps I took while following that article. Starting with a clean Ubuntu 16.04.1 server install. … Continue reading “Server Upgrade: Part 2 – Basic OS setup”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-1540","post","type-post","status-publish","format-standard","hentry","category-computing"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1540","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=1540"}],"version-history":[{"count":10,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1540\/revisions"}],"predecessor-version":[{"id":1588,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/1540\/revisions\/1588"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=1540"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=1540"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=1540"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}