Ubuntu Xenial подготовка системы к использованию

Набор шагов как настроить систему Ubuntu Xenial Server для последующего использования. Это моя задумка собрать те шаги которые использую я в своих проектах и тестах под виртуализацией, к примеру: Vmware, VirtualBoX.

Шаг №1:

ekzorchik@srv-xenial:~$ sudo rm -Rf /var/lib/apt/lists/

ekzorchik@srv-xenial:~$ sudo nano /etc/update-manager/release-upgrades

Prompt=never

ekzorchik@srv-xenial:~$ sudo nano /etc/default/apport

enabled=0

ekzorchik@srv-xenial:~$ sudo rm -Rf /var/lib/dpkg/lock

ekzorchik@srv-xenial:~$ sudo apt-get update && sudo apt-get upgrade -y

ekzorchik@srv-xenial:~$ uname -a && lsb_release -a

Linux srv-xenial 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

No LSB modules are available.

Distributor ID: Ubuntu

Description: Ubuntu 16.04.3 LTS

Release: 16.04

Codename: xenial

Шаг №2:

ekzorchik@srv-xenial:~$ sudo rm /etc/localtime

ekzorchik@srv-xenial:~$ sudo ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

Шаг №3:

Теперь нужно проверить, что текущий пользователь заданный в процессе установки из образа, в моем случае это учетная запись с логином ekzorchik имеет доступ к запуску привилегированных команд:

ekzorchik@srv-xenial:~$ cat /etc/group | grep sudo

sudo:x:27:ekzorchik

если в группе sudo нет никого, то добавляем в нее вот так:

ekzorchik@srv-xenial:~$ sudo -i

root@srv-xenial:~# usermod -aG sudo ekzorchik

root@srv-xenial:~# exit

logout

На заметку: Я для себя выработал привычку, что все действия необходимые для запуска команд с повышенными привилегиями я делаю с использованием утилиты sudo, а не от имени суперпользователя root посредством перехода sudo -i.

Шаг №4:

Удаляю дефолтные ключи ssh на системе:

ekzorchik@srv-xenial:~$ sudo rm -r /etc/ssh/ssh*key

ekzorchik@srv-xenial:~$ sudo rm -r /etc/ssh/ssh*key.pub

Создаю собственные текущей системы: (везде на запрос просто нажимаю клавишу Enter)

ekzorchik@srv-xenial:~$ sudo ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

ekzorchik@srv-xenial:~$ sudo ssh-keygen -t ecdsa -f /etc/ssh/ssh_host_ecdsa_key

ekzorchik@srv-xenial:~$ sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key

ekzorchik@srv-xenial:~$ sudo ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

На заметку: в собственных публичных ключах подключение только от имени суперпользователя текущей системы.

Теперь настрою доступ к этой системе через удаленное соединение посредством публичного ключа этой системы, а не как сейчас и по дефолту с использованием логина и пароля:

ekzorchik@srv-xenial:~$ ssh-keygen → после везде нажимаем клавишу Enter и не защищаем парольной фразой ключи, если это сделать (для пущей безопасности), то при удаленном подключении к этой системе сперва нужно будет ввести пароль на разблокировку парольной фразы, а уже потом к самой системе, что зачастую не удобно.

Generating public/private rsa key pair.

Enter file in which to save the key (/home/ekzorchik/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /home/ekzorchik/.ssh/id_rsa.

Your public key has been saved in /home/ekzorchik/.ssh/id_rsa.pub.

Теперь в пользовательском каталоге будет создана скрытая папка (начинается с символа точки перед именование папки) в которой располагается:

ekzorchik@srv-xenial:~$ ls -l ~/ekzorchik/.ssh

• id_dsa → это секретный ключ этой системы (ни в коем случае не передавать на какую-либо станцию)
• id_key.pub → это публичный ключ этой системы который нужно скопировать на удаленную систему с которой нужно подключаться к этой без ввода логина и пароля.

Шаг №5:

Копирую публичный ключ это системы на удаленную систему:

ekzorchik@srv-xenial:~$ ssh-copy-id -p 22 aollo@10.9.9.254 -f

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/ekzorchik/.ssh/id_rsa.pub"

aollo@10.9.9.254's password: <ввожу пароль на учетную запись aollo удаленной системы>

Number of key(s) added: 1 → публичный ключ успешно добавлен

Now try logging into the machine, with: "ssh 'aollo@10.9.9.254'"

and check to make sure that only the key(s) you wanted were added.

Либо еще так можно скопировать публичный ключ:

ekzorchik@srv-xenial:~$ cat ~/.ssh/id_rsa.pub | ssh -p 22 aollo@10.9.9.254 'umask 066;test -d .ssh || mkdir .ssh; cat >> .ssh/authorized_keys'

Шаг №6:

Публичный ключ на удаленной системе располагается в файле authorized_keys пользовательского каталога ~.ssh пользователя кому он был скопирован при подключении выше, в моем случае это: aollo@work:~$ cat .ssh/authorized_keys, приводить содержимое данного файла излишне, но следует обратить внимание чтобы в конце зашифрованного была надпись: ekzorchik@srv-xenial обозначающая под какой учетной записью работает данный публичный ключ.

Шаг №7:

Затем вношу изменения в конфигурационный файл сервиса SSH на предмет смены типа аутентификации:

ekzorchik@srv-xenial:~$ sudo nano /etc/ssh/sshd_config

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

HostKey /etc/ssh/ssh_host_ecdsa_key

HostKey /etc/ssh/ssh_host_ed25519_key

#PasswordAuthentication yes

RSAAuthentication yes

PasswordAuthentication no

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

ChallengeResponseAuthentication no

Шаг №8:

Затем перезапускаю сервис SSH для применения внесенных изменений в конфигурационный файл:

ekzorchik@srv-xenial:~$ sudo service ssh restart

На заметку: Важно! Та сессия с которой Вы удаленно настраиваете авторизацию на основе SSH ключей, не отключайте ее пока у Вас все не заработает иначе останетесь без доступа к системе и только через другие приложения удаленного подключения к серверу доступ можно будет восстановить. Например, vSphere Client, iLo, IPMI, локально (мышь + клавиатура + монитор).

Шаг №9:

Пробую подключиться с удаленной системы (Ubuntu Trusty Desktop) через добавленный публичный ключ к текущей, т. е. На базе операционной системы Ubuntu Xenial это заметки:

aollo@work:~$ ssh -l ekzorchik 10.9.9.129

Permission denied (publickey).

Хм, странно а почему? У Вас все по началу может быть точно также не заработать, см. логи на сервере:

ekzorchik@srv-xenial:~$ sudo tail -f /var/log/auth.log

Sep 26 08:47:31 srv-xenial sudo: pam_unix(sudo:session): session opened for user root by ekzorchik(uid=0)

Sep 26 08:48:41 srv-xenial sshd[17416]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Анализирую какая версия пакета OpenSSH у меня установлена, как на Ubuntu Trusty так и на Ubuntu Xenial:

• Ubuntu Trusty:

aollo@work:~$ ssh -V

OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.8, OpenSSL 1.0.1f 6 Jan 2014

• Ubuntu Xenial:

ekzorchik@srv-xenial:~$ ssh -V

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g 1 Mar 2016

Как я понял в версии OpenSSH 7.2 (http://www.openssh.com/txt/release-7.2) применяется новая схема шифрования.

Делаю вывод, что увы авторизация на основе публичных ключей с других систем где версия пакета OpenSSH больше чем 6.6 не будет работать (у меня пока не получилось заставить работать, также если с Ubuntu Xenial подключаться к Ubuntu Xenial), а раз так, что значит авторизация по логину и паролю + настройки безопасности для подключения:

• смена дефолтного пароля (Port)
• Принудительное указание кому разрешено подключение (AllowUsers)

Шаг №10: Настраиваю брандмауэр

ekzorchik@srv-xenial:~$ sudo nano /etc/default/ufw

#IPV6=yes

ekzorchik@srv-xenial:~$ sudo ufw status

Status: inactive

ekzorchik@srv-xenial:~$ sudo ufw app list

Available applications:

OpenSSH

ekzorchik@srv-xenial:~$ sudo ufw allow OpenSSH

Rules updated

ekzorchik@srv-xenial:~$ sudo ufw enable

Command may disrupt existing ssh connections. Proceed with operation (y|n)? y

Firewall is active and enabled on system startup

ekzorchik@srv-xenial:~$ sudo ufw status

Status: active
To Action From

-- ------ ----

OpenSSH ALLOW Anywhere

Если порт отличается от дефолтного (port 22/tcp), то добавить его в разрешающее правило можно так:

ekzorchik@srv-xenial:~$ sudo ufw allow to any port 2280

На заметку: как использовать пакет ufw советую, как почитать мануал так и мою заметку.

Шаг №11: защита доступа через сервис SSH посредством Fail2Ban от попыток подобрать пароль:

ekzorchik@srv-xenial:~$ sudo nano /etc/fail2ban/jail.conf

[ufw-ssh]

enabled = true

action = ufw-ssh

port = 22

filter = sshd

logpath = /var/log/auth.log

maxretry = 5

findtime = 300

bantime = 86400

ekzorchik@srv-xenial:~$ sudo nano /etc/fail2ban/action.d/ufw-ssh.conf

actionban = ufw insert 1 deny from <IP> to any app OpenSSH

ctionunban = ufw delete deny from <IP> to any app OpenSSH

ekzorchik@srv-xenial:~$ sudo service fail2ban restart

ekzorchik@srv-xenial:~$ sudo service fail2ban status

● fail2ban.service - Fail2Ban Service

Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset:

Active: active (running) since Tue 2017-09-26 11:08:37 MSK; 3s ago

Docs: man:fail2ban(1)

ekzorchik@srv-xenial:~$ sudo fail2ban-client status ufw-ssh

Status for the jail: ufw-ssh

|- Filter

| |- Currently failed: 0

| |- Total failed: 0

| `- File list: /var/log/auth.log

`- Actions

|- Currently banned: 0

|- Total banned: 0

`- Banned IP list:

Шаг №12: Безопасность shared memory

ekzorchik@srv-xenial:~$ sudo nano /etc/fstab

tmpfs /run/shm tmpfs defaults,noexec,nosuid 0 0

ekzorchik@srv-xenial:~$ sudo mount -a

Вот такими базовыми действиями настраивает система Ubuntu Xenial Server. Но не спорю — это не все, в последующем я буду наполнять данную заметку своими наработками. А пока собственно и всё, с уважением автор блога Олло Александр aka ekzorchik.