Secure Shell SSH Руководство

Учебное пособие по этому великолепному протоколу, начавшему свое появление в 1997 году, предлагающее широкий спектр инструментов, которые выделяются своей безопасностью, будучи очень обширным, я разделю его на несколько статей, пытаясь охватить наиболее важные как на уровне клиента, так и на уровне сервера.

Что такое протокол Secure Shell?

Secure Shell или SSH - это сетевой протокол, который позволяет обмениваться данными по защищенному каналу между двумя компьютерами. SSH использует методы шифрования, которые делают информацию, проходящую через носитель, недоступной для чтения, и никакая третья сторона не может обнаружить имя пользователя и пароль соединения или то, что написано в течение сеанса. SSH использует криптографию с открытым ключом для аутентификации удаленного компьютера и позволяет ему аутентифицировать пользователя при необходимости.

SSH обычно используется для запуска сеанса на удаленной машине, где вы можете выполнять заказы, но он также позволяет выполнять туннелирование, произвольно перенаправлять порты TCP и соединения X11; Передача файлов также может осуществляться с использованием соответствующих протоколов SFTP или SCP.

Мы видим, что его привлекательность более чем достаточна для перехода к старому протоколу TELNET, в котором отсутствует шифрование информации, что ставит под угрозу данные и даже учетные данные для доступа.

Сервер SSH по умолчанию предлагает TCP-порт 22. Клиент SSH обычно используется для установления соединений с сервером sshd, который принимает удаленные соединения. Оба они обычно встречаются в самых современных операционных системах, включая Mac, Linux, Solaris и OpenVMS.

Ожидается, что поддержка Windows его серверной версии будет официально выпущена в этом году, в то время как на уровне клиента она предлагает широкий выбор опций, выделяющих PuTTY над другими.

Научитесь использовать Putty

OpenSSH

OpenSSH (Open Secure Shell) - это набор приложений, которые позволяют зашифрованную связь по сети с использованием протокола SSH. Он был создан как бесплатная и открытая альтернатива протоколу SSH, он наиболее часто используется в Linux и будет тем, который мы будем использовать в записях.

1. Установите Secure Shell SSH

Почти во всех дистрибутивах его клиентская версия предустановлена, а его серверная версия доступна в репозитории, его установка должна быть очень простой.

Debian, Ubuntu, Linux Mint и производные

 sudo apt-get установить openssh-сервер 

Centos, Rhel, Fedora

 sudo yum установить openssh-сервер 

Arch-Linux

 Пакман -Сю опеншш 

Мы проверяем, что вы работаете с:

 curl: 22 

Если вы бежите правильно, вы должны бросить:

[color = # 696969] [/ color]

Подключение к серверу
Используя клиент, мы можем подключиться к серверу, который может быть удаленным, даже если у нас обе версии подключены внутри, используя localhost.

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

 ssh 

В случае внутреннего подключения это будет:

 ssh 

При подключении у нас есть множество вариантов, я объясню некоторые очень полезные, вы можете перечислить все варианты с помощью:

 человек сш 

Здесь мы покажем вам:

Варианты SSH man
-С

Запросите сжатие данных, сохраняя пропускную способность или данные, если вы находитесь в мобильной сети.

-l

Укажите пользователя, с которым мы будем связываться.

-E

Создайте файл журнала, в котором стандартная ошибка будет отклоняться.

-F

Мы выбираем другой файл конфигурации, полезный для серверов с необычными опциями.

-g

Необходимо сделать туннелирование портов.

-i

Мы выбираем папку, которую будем использовать для альтернативного закрытого ключа.

-К

Включить при использовании учетных данных GSSAPI.

-n

Используйте его вместе с X11, чтобы весь журнал, созданный приложением, перенаправлялся в / dev / null.

-или

Требуется для использования более сложных параметров, таких как ServerAliveInterval 30.

-p

Выберите порт, отличный от 22, для подключения к хосту.

-v

Показать все необходимые шаги, чтобы установить соединение, вы можете получить еще больше информации с -vv -vvv.

-X

Необходимо, если мы хотим использовать Пересылку X11.

и

Включите безопасную пересылку X11.

Мы подключимся к серверу test.solvetic.com с пользователем jcarrillo, используя другой закрытый ключ, расположенный в нашей папке / home / jcarrillo / keys-aws, используя порт 8022 нашего экземпляра в AWS.

 Пример → ssh -C -i «~ / keys-aws /» -p 8022 -l jcarrillo test.solvetic.com 

Как мы видим, это обширный, но очень полный инструмент, который заслуживает большего количества записей, чтобы иметь возможность охватить его необходимые функции для любого промежуточного или профессионального сисадмина.

$config[ads_text6] not found

Теперь перейдем к его конфигурации клиент-сервер, сгенерируем открытый и закрытый ключи, используем переадресацию портов в реальных ситуациях, перенаправление с сервера X на X11, используем scp, sftp, ssh-agent и другие.

2. Защита SSH-сервера

Мы продолжаем с OpenSSH, сосредотачиваясь на защите нашего SSH Сервера, чтобы избежать всех типов атак, которые могут поставить под угрозу наш Сервер. Все эти конфигурации будут сделаны в файле sshd_config, расположенном в / etc / ssh /, который мы можем изменить с помощью любого текстового редактора в моем случае, используя vim:

 sudo vim / etc / ssh / sshd_config 

Теперь мы видим, как его изменить.

Изменить sshd_config
Внутри мы увидим типичный файл конфигурации, основанный на «значении параметра», если какой-либо из параметров не найден по умолчанию, мы должны поместить строку полностью, в других случаях это будет только изменение с 0 на 1 с Нет на Да или раскомментирование строки.

Изменить порт 22
Важно изменить порт по умолчанию на случайный, если для атаки на этот порт настроено много сценариев, рекомендуется изменить его в диапазоне от 1000 до 23000, чтобы он не использовался другим сервисом.

Мы также не должны использовать такие порты, как 2222, 8022 или 1022, так же часто, как 22, и многие скрипты настроены для их атаки.

порт 2345

Если у нас включен SELINUX, мы должны использовать дополнительную команду, чтобы разрешить доступ извне к новому порту.

неделя порт -a -t ssh_port_t -p tcp 2345 # Изменение порта 22 для безопасности

Использовать протокол 2 по умолчанию
Мы должны убедиться, что все наши соединения сделаны в соответствии с Протоколом 2, 1 имеет много уязвимостей.

$config[ads_text6] not found

Протокол 2

Время для ввода учетных данных
Поиск в разделе «Аутентификация» . Ваши первые два варианта также важны. Первая - это количество секунд, в течение которых удаленный пользователь должен войти в систему на вашем компьютере. Поместите это значение в течение нескольких секунд, для входа в систему не потребуется много времени, если мы знаем учетную запись и пароль.

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

LoginGraceTime 30

Отключить рут-доступ
Это самый важный вариант стать жертвой атаки, им нужно 3 вещи:

• пользователь
• порт
• пароль

Если мы отключим root, у них уже есть один, поскольку обычный пользователь является root на всех системах. В дополнение к этому, этот пользователь может нанести ущерб, включив все разрешения .

$config[ads_text5] not found

PermitRootLogin нет

Включить контролируемый доступ
Мы можем контролировать, какой пользователь может войти через SSH и даже разместить пункт для подключения только с определенного IP. Это похоже на то, что AWS предлагает для подключения к вашим экземплярам.

AllowUsers

Важно разрешить доступ только тем пользователям, которым необходим удаленный доступ, и, по возможности, ограничить их известным IP-адресом.

Установите количество неудачных попыток
Если мы неправильно введем пароль, сервер даст нам несколько попыток его повторного ввода, это должно быть ограничено, иначе вы можете стать жертвой скрипта грубой силы, мы можем разместить его 2 или 3 раза.

MaxAuthTries 2

Количество соединений, разрешенных одновременно
Это может варьироваться в зависимости от использования, которое вы предоставляете серверу, но в идеале вы должны управлять им, просто добавьте общее количество пользователей, разрешенных SSH.

$config[ads_text6] not found

MaxStartups X

После внесения всех изменений в наш файл мы должны перезапустить наш сервис sshd, он может отличаться в зависимости от менеджера сервиса.

Systemd

 systemctl перезапустить sshd 

Upstart / Sysinit

 перезапуск службы sshd 

Все эти изменения добавляют дополнительный уровень безопасности, но мы должны помнить:

• Используйте буквенно-цифровые пароли.
• Всегда используйте Аутентификацию с открытым / закрытым ключом .
• Дополните безопасность с помощью SELINUX и брандмауэров.
• Контроль доступа, к которому пользователи должны войти удаленно.

Аутентификация SSH публичных / приватных ключей

В настоящее время использование SSH-ключей является обязательным требованием, эта аутентификация широко используется администраторами для автоматизации задач между несколькими серверами и даже используется разработчиками для доступа к SCM, таким как GIT, GITHUB, GITLAB и других.

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

Используя ключ SSH (открытый и закрытый), они могут легко подключаться к серверу или нескольким серверам без необходимости каждый раз вводить пароль. Можно настроить ваши ключи без парольной фразы, однако это будет неосторожно, если кто-то получит ваш пароль, он сможет его использовать. Мы поговорим о том, как генерировать ключи, распространять их и использовать ssh-agent для получения большей безопасности.

Генерация ключей без пароля
Прежде всего, убедитесь, что у вас установлен OpenSSH, сервер - это не просто клиент.

$config[ads_text5] not found

Мы начнем с генерации ключа типа DSA с 1024-битной защитой, более чем достаточно, хотя вы можете пойти дальше и сгенерировать ключ типа RSA с остановкой 4096.

 ssh-keygen -b 1024 -t dsa 

Он попросит нас указать место, где вы будете хранить ключи по умолчанию ~ / .ssh

 Введите файл для сохранения ключа (/home/test/.ssh/id_dsa) 

Затем попросите фразу, пока мы не будем ее использовать, оставьте ее пустой и сообщите нам, что ключ создан и отражает нас.

Изображение всегда будет другим, оно генерируется случайным образом, тогда, если мы перейдем в папку .ssh, у нас должно быть 2 файла

$config[ads_text6] not found

id_dsa -----> Закрытый ключ (не делитесь им ни с кем как ваш TDC).
id_dsa.pub ----> Это тот, который мы разделяем для подключения.

Поделиться открытым ключом
Если вы хотите поделиться открытым ключом в SCM или Chef, Puppet, Jenkins, мы визуализируем файл открытого ключа, копируем его и вставляем туда, где он соответствует.

 более id_dsa.pub SSH-ДСС AAAAB3NzaC1kc3MAAACBAN6SEI4Qqzb23pJYRXIAtPmGJHln5hFdthFq43ef + ifR29v2IknXCFwefKK8jorSDiUEY / 1F / yp0xao mjhFQu1jNXOgF0PAZTfivRVFn6Q9FRsyXU9s + Fx + xQiW3mf3y4IX654O82SLGl7Vhh5UsvG8r8d8pV6R + L22sV7GkCHPxAAAAFQCyF1Gdh3 Cap4xr / 0gFArHmFwAxfQAAAIEAmVYjPYAdQ9DCNWP + J44xDDn + 03anWgyoZqSPPs23djyVQ756U4VitM0GiIQQ89HCdvTFFpSagnfdVpWh4 Hxo4Y5skKihnPMtB + bFNbP / 2SmGdPz1AOmb7tvRrTkj5VLtXeDeB3ulowUKarwiBVVvAvxtxmozoZHOADWqrEPizxIAAACAU2DF1ZGTiJMP 1oXguj + OhVB7mlsVhhkq53OxKKJbZqsl9hkOiSxaLUfQBNu6Ae441ekIObqolWNCBIvCO3uQYOozyzNGBhqHE7FVq + UGNkee96D2by + 2GAQ S7daieIKNmFer2hO / SBxzepMrWAiIUnUsP5irmYspkjGlQxP + = HxW 

Если вы хотите поделиться им для доступа к серверу, я всегда рекомендую использовать ssh-copy-id, включенный в OpenSSH и очень простой в использовании:

 ssh-copy-id -i указывает местоположение используемого ключа. 

Есть и другие способы, такие как:

 ssh \ 'cat >> .ssh / authorized_keys2' <.ssh / id_dsa.pub 

 scp ~ / .ssh / id_dsa.pub [электронная почта защищена] 

Отныне ключи подключены и нужно только ввести хост.

 ssh -l user remote-server-ip 

На этот раз он не будет запрашивать пароль, и мы можем использовать сценарии без взаимодействия.

Генерация парольной фразы и связывание с ssh-agent
Безопасность ключей SSH основана на нашем закрытом ключе, который работает как карта доступа, но в случае кражи нашего ключа вы можете получить доступ ко всем местам, к которым у нас есть доступ. Но при генерации ключевой фразы у нас может быть дополнительный уровень, необходим не только ключ, но и ввод нашей фразы.

На этот раз мы создадим ключ rsa с большей безопасностью, настроив фразу.

 ssh-keygen -b 4096 -t rsa -C «Ключ с парольной фразой» # -C Добавить комментарий. 

В качестве фразы мы можем использовать пробелы, пробелы и специальные символы

 пример ---> [электронная почта защищена] - мой [защищенный электронной почтой] ключ с [электронной почтой] 

Мы делимся новым ключом:

 scp ~ / .ssh / id_rsa.pub [электронная почта защищена] 

На этот раз нам нужен ключ и пароль, но вводить его несколько раз утомительно, но мы можем дополнить его ssh-agent, мы должны его запустить.

 SSH-агент 

Мы добавляем наш ключ

 ssh-add Введите ключевую фразу для /home/user/.ssh/id_rsa: # Введите настроенную фразу. 

Теперь мы можем подключиться к любому серверу, который использует наш ключ, не вводя нашу фразу-пароль .

Я рекомендую этот метод, если вы находитесь за пределами интрасети, клиента и сервера в разных точках Интернета, и мы не будем использовать автоматизированные задачи, а вместо этого мы будем подключаться к серверу для целей удаленного администрирования, лучше указать пароль или Очень длинная фраза (15 или более символов, прописные, строчные, цифры и символы) для открытого ключа.

Таким образом, этот метод будет практически невозможен для взлома, поскольку хакер должен будет не только знать пароль, но и иметь действующий общедоступный сертификат на сервере для аутентификации. (Конечно, при условии, что сервер никогда не был скомпрометирован и полностью обновлен и имеет наилучшую возможную безопасность) .

• 
• 0