US: +1 561 2500001/EU: +359 2 4925555 LiveChat
[email protected] Sign Up Login
ITLDC
  • SSD VDS
  • HD VDS
  • Серверы
  • Хостинг
  • Поддержка
  • Блог
  • Контакт
  • [EN]
  • [UA]
  • SSD VDS
  • HD VDS
  • Серверы
  • Хостинг
  • Поддержка
  • Блог
  • Контакт
  • [EN]
  • [UA]

Google Authentificator: защищаем SSH

Google Authentificator: защищаем SSH

Апр 8, 2014DmitryНовости

Обычно используется два варианта проверки пользователя при доступе с использованием ssh — по ключу и по паролю. Несомненно, авторизация по ключу является значительно более безопасным способом, но этот вариант не всегда возможен. Например, если вход происходит со «чужого» компьютера, где сложно или небезопасно разместить приватный ключ, приходится пользоваться обычным доступом с использованием пароля.

Вне зависимости от сложности пароля всегда есть риск его «утечки». Как показывает опыт, пароль может быть получен злоумышленником несколькими способами, наиболее частые из них — keylogger на компьютере пользователя либо перехват пароля с помощью троянов на стороне сервера. Именно поэтому есть смысл внедрить дополнительный способ проверки пользователя — воспользоваться технологией TOTP.

TOTP — это дополнительные случайные одноразовые коды верификации, сгенерированые по специальному алгоритму. На стороне клиента эти коды могут быть получены с помощью различных способов. Провайдер TOTP может выслать код по SMS на мобильный телефон пользователя, есть брелки-токены с небольшим LCD-дисплеем, но наиболее массовым решением обычно считают специальные приложения для современных смартфонов.

Мы воспользуемся одним из популярных решений — Google Authentificator. Это универсальный продукт, который можно использовать не только для дополнительной защиты SSH-сервера — можно включить опцию использования TOTP в продуктах Google, в WordPress, Facebook, Joomla, Dropbox и многих других продуктах и сервисах. Приложение Google Authentificator доступно для IOS, Android, Windows mobile.

Итак, установим Google Authenificator на свое мобильное устройство и приступим к настройке нашего Centos-сервера. Для начала — подключим репозиторий EPEL и обязательно включим синхронизацию времени:

1
2
3
4
5
wget http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
rpm -ivh epel-release-6-8.noarch.rpm
yum install ntp
chkconfig ntpd on
service ntpd start

Установка Google Authernificator после этого производится одной командой:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
yum install google-authenticator</a>
 
После установки запустим утилиту для того, чтобы указать общие настройки, и получить начальные данные для настройки токена на мобильном устройстве:
 
<pre class="lang:default decode:true " ># google-authenticator
https://www.google.com/chart?chs=200x200&chld=M|0&cht=qr&chl=otpauth://totp/[email protected]%3Fsecret%3D6JXXXXXXXXXXXTX
Your new secret key is: 6JXXXXXXXXXXXTX
Your verification code is XXXXX
Your emergency scratch codes are:
  8XXXXXX5
  4XXXXXX7
  7XXXXXX3
  2XXXXXX9
  2XXXXXX0
 
Do you want me to update your "~/.google_authenticator" file (y/n) y
 
Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
 
By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) y
 
If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
#

Самый простой вариант настройки мобильного токена — загрузить в броузере настольного компютера QR-код по указанной ссылке, а в приложении на сматрфоне выбрать «Добавить запись» и затем «Сканировать штрихкод». После этого наш сматрфон будет генерировать каждые 30 секунд уникальный код, который будет необходим для доступа к серверу.

Перейдем к настройке SSH-сервера. В самом начале файла конфигурации PAM /etc/pam.d/sshd подключим соотвествующий модуль:

1
auth       required     pam_google_authenticator.so

Далее, откроем в любимом текстовом редакторе основной конфигурационный файл sshd (/etc/ssh/sshd_config) и установим параметр:

1
ChallengeResponseAuthentication yes

После этого перезапустим sshd:

1
service sshd restart

На этом настройка закончена. Попробуем подключиться с другого компьютера и проверим. Вначале удаленный сервер даст запрос на ввод кода верификации, нужно будет ввести полученное в приложении Google Authentificator шестизначное число. Затем сервер выдаст запрос на ввод пароля, укажем его и получим доступ к нашему серверу:

1
2
3
4
desktop# ssh [email protected]
Verification code:
Password:
server#

В том случае, если используется авторизация по ключу, Google Authentificator не будет требовать ввода кода верификации — дополнительная проверка проводится только при авторизации с использованием пароля.

В заключение — несколько рекомендаций:

  • Когда возможно — используйте ssh-авторизацию с использованием ключей.
  • Используйте отдельный пароль для защиты приватного ключа, не храните ключ в незашифрованном виде
  • Минимальная длина пароля должна быть 12-14 символов
  • Пароль должен содержать буквы в разных регистрах, цифры и спецсимволы
  • Если возможно, измените порт sshd на другой, нестандартный

Удачной и безопасной работы!

Tags: centos,  security,  ssh
Related Posts
  • Серьезная уязвимость в устройствах Mikrotik

  • Выпущен Centos 8

  • Как «растянуть» файловую систему VDS после смены тарифа без потери данных?

  • CVE-2019-0708: Критическая уязвимость RDP в Windows

← Автоматизация облаков — запускаем вторичные DNS с помощью Ansible
Уязвимость в OpenSSL «Heartbleed» →

Recent Posts

  • ITLDC News — December 2022
    ITLDC News — December 2022

    We did not publish updates for November...

  • Let’s start our biggest SALE!
    Let’s start our biggest SALE!

    We will not complicate and publish some...

  • ITLDC News — October 2022
    ITLDC News — October 2022

    It's time to make a brief report on what...

  • Price adjustments for selected services
    Price adjustments for selected services

    Since the autumn of last year, the price...

  • Support for our friends and colleagues in Ukraine
    Support for our friends and colleagues in Ukraine

    Dear friends and colleagues from Ukraine...

  • Новый датацентр — UA2.IEV: Kyiv, Ukraine!
    Новый датацентр — UA2.IEV: Kyiv, Ukraine!

    Мы продолжаем увеличивать количество наш...

  • CyberMonday — продолжаем марафон скидок!
    CyberMonday — продолжаем марафон скидок!

    Черная Пятница прошла, но не будем остан...

  • Black Friday 2021 — скидки до 50% на все SSD VDS!
    Black Friday 2021 — скидки до 50% на все SSD VDS!

    Черная Пятница официально началась! На п...

EU Support

ITLDC EU Team

PO Box #201
Burgas
Burgas reg. 8000
Bulgaria

+1 561 2500001

[email protected]

US/APAC Support

ITLDC NOAM Team

PO Box 800054
Aventura
FL, 33280
USA

+1 561 2500001

[email protected]

Services

  • SSD VDS
  • Dedicated Servers
  • Shared Hosting
  • Colocation
  • DDoS Protection
  • SSL Certificates
  • Backup Storage
  • Reselling

Support

  • Get Help
  • ITLDC Status
  • Looking Glass
  • Our SLA
  • Datacenters
  • FAQ & Knowledgebase
  • Data Security
  • Contact us

© Copyright 1995-2019 ITLDC Team. You can freely use or share information from this site with a hyperlink to the original page.