![]() |
SSH — это исключительно удобный и полезный инструмент, издавна ставший стандартом де-факто в UNIX-сетях. С помощью этого протокола вы можете безопасно подключаться к удаленному серверу и выполнять на нем какие-то команды или копировать файлы — весь трафик шифруется, и злоумышленник не сможет прочитать передаваемые данные. Однако есть у SSH и недостаток, прямо вытекающий из его достоинств: для подключения к удаленной системе вам требуется ввести пароль...
Разумеется, SSH шифрует в том числе и передаваемые пароли, так что опасность перехвата вам не грозит. Но вот постоянно печатать одно и то же надоедает.
Да и в скриптах использовать безопасные соединения становится неудобно. К счастью, SSH предоставляет возможность помимо интерактивной аутентификации использовать еще и аутентификацию по ключу.
Шифрование с открытым ключом прекрасно подходит для работы с незащищенными каналами связи — например, с Интернетом
В SSH используется шифрование с открытым ключом, что означает использование двух ключей: секретного и открытого. Секретный ключ хранится локально и никуда не передается, в то время как публичный ключ может быть передан корреспонденту по открытым (небезопасным) каналам связи. После того как корреспонденты обменялись публичными ключами, они получают возможность обмениваться и сообщениями: каждое сообщение для корреспондента А шифруется с использованием его открытого ключа, а расшифровано может быть только при помощи секретного (единственный экземпляр которого есть у А). То есть, когда вы подключаетесь к серверу, он находит ваш публичный ключ, генерирует некую случайную строку, шифрует ее и пересылает вам. Ваш компьютер эту строку расшифровывает и пересылает обратно на сервер, подтверждая, что никакого подлога нет и компьютер действительно обладает соответствующим секретным ключом. Ну а после этого уже начинается сам процесс обмена данными.
В реальности все, разумеется, немножко сложнее: во-первых, используются как ключи хоста (для подтверждения того, что вы общаетесь именно с тем компьютером, с которым планировали), так и ключи пользователя (чтобы подтвердить, что у вас есть право выполнять какие-то действия на удаленной машине); во-вторых, сообщения подписываются секретным ключом хоста-отправителя (чтобы вы могли убедиться, что пришедшее сообщение не является подделкой), ну а в-третьих, в-четвертых и в-пятых мы опустим — при желании вы за несколько минут сможете в Интернете найти все требуемые вам технические подробности, которые обычного пользователя мало интересуют.
Секретный ключ потому и называется секретным, что его надо держать в секрете!
В целях обеспечения дополнительной безопасности хранящийся у вас на компьютере секретный ключ тоже можно зашифровать с использованием какого-то пароля — это не позволит злоумышленнику, получившему доступ к вашему компьютеру, подключиться к удаленному серверу от вашего имени. При попытке использования такого зашифрованного ключа система попросит вас ввести пароль (который в данном случае никуда не передается, а используется только для расшифровки ключа).
При использовании SSH в скриптах придется пойти на компромисс между безопасностью и удобством
Однако если вы решите использовать защищенные соединения в своих скриптах, то вам понадобится организовать такую схему, при которой пароль бы не запрашивался вовсе. Для этого вам придется создать незашифрованный секретный ключ, что, конечно, несколько снижает безопасность системы, но является значительно более надежным, чем использование большинства других методов.
Итак, предположим, что вы хотите создать скрипт, который будет создавать резервную копию вашего веб-сайта на каком-то удаленном компьютере.
ssh-keygen — утилита для создания ключей
Первым делом вам надо создать пару ключей:
ssh-keygen -t rsa
В ответ на это система скажет:
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
После этого система спросит пароль, с помощью которого будет зашифрован секретный ключ. Так как мы создаем ключи для использования в скриптах, то оставляем пароль пустым. Дважды нажимаем на Enter, и система рапортует об успешном создании ключей:
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
9a:a9:39:6f:1c:af:03:4c:da:68:24:7f:8d:d9:f8:c9 user@localmachine
Кроме вас, читать ваш ключ никому не надо
Если вы теперь заглянете в директорию /home/user/.ssh/, то обнаружите там два файла: id_rsa (секретный ключ) и id_rsa.pub (публичный). На всякий случай стоит сразу запретить посторонним доступ к вашему секретному ключу:
chmod 600 ~/.ssh/id_rsa
Большинство современных систем назначают такие права автоматически, но всегда лучше подстраховаться.
SCP — утилита для безопасной пересылки файлов
Теперь настает время переслать наш ключ на удаленную машину. Для этого вам необходимо иметь там аккаунт — не может же система разрешить кому угодно к ней подключаться. Пишем:
scp ~/.ssh/id_rsa.pub user@remotemachine:/home/user/id_rsa.pub
SCP — Secure CoPy — позволяет безопасно пересылать файлы, используя все тот же протокол SSH. Однако, так как у нас пока еще не организована авторизация по ключу, система запросит у вас пароль и после его проверки положит файл с публичным ключом в вашу домашнюю директорию на удаленном сервере.
id_rsa.pub 100% |*****************************| 238 00:00
Команда ssh позволяет выполнять команды на удаленном компьютере как в интерактивном, так и в автоматическом режиме
Нам осталось подключиться к удаленной машине и переложить ключи в положенное место:
ssh user@remotemachine "mkdir ~/.ssh; cat ~/id_rsa.pub >> ~/.ssh/authorized_keys && rm ~/id_rsa.pub"
Удаленный компьютер спросит ваш пароль (вероятно, в последний раз!), после чего создаст в вашем домашнем каталоге на удаленном сервере директорию .ssh (а если вы SSH уже пользовались, то сообщит, что такая директория существует), потом допишет в конец файла authorized_keys ваш публичный ключ (если этот файл не существует, то он будет создан) и, если запись в файл пройдет успешно, удалит ваш id_rsa.pub из домашней директории.
Использование незашифрованных ключей позволяет создавать SSH-соединение, не вводя никакого пароля
По идее, вы уже можете подключаться, не вводя никакого пароля. Попробуйте набрать, например:
ssh user@remotemachine
Если все прошло гладко, вы увидете консоль удаленного сервера. А если имя пользователя на локальной и удаленной машине совпадает, то user@ можно не писать — достаточно указать только имя (или адрес) машины.
Когда ключи созданы, вы можете использовать команды ssh и scp в своих скриптах
И последнее, что осталось, это написать сам скрипт. В самом простом случае это может быть что-то похожее на это:
#!/usr/local/bin/bash
/bin/tar -zcpf ~/mysite.tar.gz /www
scp ~/mysite.tar.gz remotemachine:~/mysite.tar.gz
ssh remotemachine "/bin/tar -zxf ~/mysite.tar.gz"
Разумеется, для реального использования этот скрипт надо будет капитально переработать, подогнав под ваши потребности, но это уже выходит за рамки данной статьи. Все, что я хотел показать, — это как использовать безопасные соединения для передачи данных.
SSH тоже надо защищать: перекройте его файрволом и запретите интерактивную авторизацию
![]() |
Ну и в конце этой заметки еще несколько замечаний по безопасности. SSH работает вполне надежно, но только до тех пор, пока ваш пароль не попал в руки злоумышленников. Если заглянуть в логи сервера, то наверняка вы обнаружите достаточное количество попыток подключиться и подобрать пароль: как правило, это работают разные автоматические скрипты, перебирающие наиболее распространенные пары логин/пароль, но встречаются и целенаправленные атаки на какой-то сайт. В качестве самых базовых рекомендаций можно посоветовать разрешить в брандмауэре подключения к 22-му порту только с разрешенных адресов и диапазонов сетей (вы можете прописать, например, IP-адрес своего основного сервера, сеть вашего провайдера и свой рабочий IP, а для подключения во время поездок можно использовать, скажем, какую-нибудь систему удаленного управления рабочим или домашним компьютером, с которого уже подключаться к серверу). Помимо защиты от подбора пароля файрвол сможет защитить ваш сервер и от DOS-атак на SSH-сервер. Дополнительно можно запретить интерактивное (с использованием пароля) подключение к SSH — оставить только авторизацию по ключу. В этом случае вам надо будет только следить, чтобы секретный ключ не попал в руки к злоумышленникам (и, разумеется, чтобы у вас была его резервная копия, иначе в случае каких-то проблем вам будет очень сложно попасть на сервер).
Успехов вам и вашему сайту!
Ссылки по теме
Статья получена: hostinfo.ru