В этой статье мы рассмотрим современные и удобные способы работы с сервером по SSH с VPS от Infobox и облаком .
Мы расскажем не только про обычный способ подключения, но и про организацию устойчивого соединения через нестабильный интернет (например 3G модемы), а также о дополнительных утилитах, помогающих в работе по SSH.
Если вы пользователь Windows и вам нужно просто и быстро подключиться к Linux–серверу - переходите в раздел «Putty или как быстро подключиться к SSH из Windows».
В этом разделе вы увидите ip-адрес сервера и можете установить пароль для доступа к серверу .
Для подключения используйте имя пользователя root
, ip–адрес
с этой страницы и установленный пароль
.
Если вы забыли пароль, нажмите на пункт «Редактировать параметры доступа», показанном на скриншоте выше.
Затем перейдите во вкладку «Управление VPS».
Используйте имя пользователя root
, пароль и ip–адрес сервера с этой страницы.
Войдите в панель управления по адресу: https://panel.infobox.ru .
Выберите услугу «Облачные серверы» в правом верхнем углу панели управления в выпадающем списке.
Выделенный IP–адрес для сервера можно посмотреть во вкладке «Облачная инфраструктура» панели управления.
Если поле "Выделенный IP адрес " пустое, значит при создании сервера вы не добавили серверу хотя бы 1 выделенный ip–адрес (и следовательно доступа через Интернет к серверу нет, есть только из локальной сети).
Чтобы добавить выделенный IP–адрес, нажмите на имя сервера.
В группе настроек «Сеть» нажмите «Настроить».
Убедитесь, что пропускная способность (скорость) сети достаточна (или поставьте больше при необходимости).
Затем нажмите «Добавить IPv4–адрес» и нажмите «Сохранить изменения».
Теперь у сервера есть выделенный IP–адрес.
Для изменения пароля доступа к серверу нажмите «Изменить», как показано на скриншоте выше. Так вы можете установить пароль для доступа к серверу.
Теперь вы знаете ip–адрес сервера
, логин (root
) и пароль
.
Запустите Putty (Пуск -> Все приложения -> PuTTY -> PuTTY).
Введите IP–адрес сервера. Убедитесь, что выбран порт 22, а тип подключения SSH и нажмите «Open».
Вам будет задан вопрос, доверяете ли вы серверу, к которому подключаетесь. Нужно ответить «Да».
Откроется окно подключения. В качестве логина используйте root, в качестве пароля - ваш пароль от сервера. Пароль можно вставить из буфера обмена правой кнопкой мыши. Он не отображается при вводе и вставке в целях безопасности.
Подключение было успешно установлено.
Autossh использует ssh для построения петли ssh–перенаправлений (соединение с локального компьютера на удаленный и в обратном направлении) и пересылает тестовые данные, ожидая, что они вернутся назад. Также поддерживается использование удаленного эхо-сервиса для отправки назад тестовых данных.
AutoSSH поддерживает только 3 параметра:
Для того, чтобы при восстановления соединения вам не пришлось вводить пароль повторно, разрешите для данного пользователя вход на сервер по ключу, как показано в разделе выше.
Теперь можно выполнить подключение к серверу:
autossh -M 20000 root@ip_адрес_сервера
Соединение успешно установлено.
В целом autossh – достаточно удобный инструмент для работы через нестабильные интернет-соединения и для организации ssh–туннелей на сервере (этот сценарий мы рассмотрим в отдельной статье). Недостаток autossh в том, что эта утилита не решает проблему, если в момент ввода команд на сети возникают значительные задержки (что в 3G сети случается). В этом случае вы будете ждать ответа от сервера на ввод каждого символа, что несколько замедляет работу. Тем не менее в обычных условиях работы autossh очень помогает поддерживать ssh–соединение.
Возможность вводить команды не дожидаясь ответа сервера решает Mosh , но совместимость этой утилиты пока сильно ограничена, а надежность невысока, поэтому пока использовать ее не рекомендуется.
1. Зайдите на удаленный сервер по SSH.
2. Запустите там screen
3. Вы увидите приветствие, нажмите Enter.
4. Теперь вы можете делать что угодно, как будто вы просто подключены к серверу по SSH (например запустите любой долгий процесс).
5. Вы можете отсоединить сессию, нажав CTRL + a, затем d. Можете даже завершить подключение по SSH к серверу.
6. Чтобы вернуться в сессию, переподключитесь по SSH (или это сделает autossh) и введите screen -r
Вы вернетесь в запущенную сессию, а в ней продолжается запущенный вами процесс ранее. Более подробно терминальные мультиплексоры мы разберем в последующих статьях.
SSH - (Secure Shell) - это протокол удаленного управления компьютером с операционной системой Linux. В основном ssh используется для удаленного управления серверами через терминал. Если вы администратор нескольких серверов или даже продвинутый веб-мастер, то наверное, вы часто сталкиваетесь с необходимостью работать с тем или иным компьютером по ssh. В Linux для этого используется сервер ssh на машине, к которой нужно подключится и клиент, на той из которой подключаются.
В этой инструкции мы рассмотрим как пользоваться ssh, а также ее возможности, о которых вы даже не знали. Скорее всего, вы уже знаете как подключиться к серверу по ssh, но у этой утилиты есть еще много возможностей, таких как передача файлов ssh, подключение без пароля или выполнение скрипта на удаленном сервере. Все это мы и рассмотрим далее в статье.
Но начнем с самых основ.
Синтаксис команды выглядит следующим образом:
$ ssh [опции] имя пользователя @сервер [команда]
Важно заметить что ssh может работать по двум версиям протокола. Версии 1 и 2. Понятное дело, что версия 2 лучше и поддерживает больше типов шифрования и аутентификации. Больше в этой статье об отличиях протоколов мы говорить не будем и я буду подразумевать что вы используете версию 2.
Теперь давайте рассмотрим самые основные опции команды ssh:
Это далеко не все опции утилиты, остальные выходят за рамки данной статьи. Многие настройки работы ssh можно изменять через конфигурационный файл ~/.ssh/config но здесь мы это тоже подробно рассматривать не будем.
Настройки сервера SSH находятся в файле /etc/ssh/sshd_config. Многие из них мы тоже трогать не будем. Рассмотрим только самые интересные. Сначала откройте файл /etc/ssh/sshd.conf
По умолчанию ssh работает на порту 22. Но такое поведение небезопасно, поскольку злоумышленник знает этот порт и может попробовать выполнить Bruteforce атаку для перебора пароля. Порт задается строчкой:
Поменяйте значение порта на нужное.
По умолчанию сервер ssh может работать по двум версиям протокола, для совместимости. Чтобы использовать только протокол версии два раскомментируйте строчку:
И приведите ее к такому виду:
По умолчанию Root доступ по ssh разрешен, но такое поведение очень небезопасно, поэтому раскомментируйте строчку:
PermitRootLogin no
Мы можем разрешить доступ к ssh только для определенного пользователя или группы. Для этого добавьте строчки:
AllowUsers User1, User2, User3
AllowGroups Group1, Group2, Group3
Здесь User1 и Group1 - пользователь и группа к которым нужно разрешить доступ.
Не все знают но есть возможность использовать ssh для запуска полноценных X11 приложений. Об этом мы поговорим ниже, но чтобы все заработало необходимо разрешить эту возможность на стороне сервера, добавьте такую строчку:
X11Forwarding yes
Основные опции рассмотрели, перед тем как переходить дальше, не забудьте перезагрузить ssh сервер чтобы сохранить изменения:
service sshd restart
Основная цель этой статьи - показать интересные и полезные способы использования ssh, о которых, возможно, вы не знали. Переходим к самому вкусному - возможности ssh.
Чтобы просто подключиться к серверу по SSH используйте такую команду:
Мы привыкли подключаться к удаленному серверу, а уже потом выполнять нужные команды, но на самом деле утилита ssh позволяет сразу выполнить нужную команду без открытия терминала удаленной машины. Например:
ssh user@host ls
Выполнит команду ls на удаленном сервере и вернет ее вывод в текущий терминал.
Выполним интерпретатор bash на удаленном сервере и передадим ему наш локальный скрипт с помощью перенаправления ввода Bash:
ssh user@host "bash -s" < script.sh
Мы можем сохранять бекэп диска сразу на удаленном сервере с помощью ssh. Перенаправим вывод dd с помощью оператора перенаправления |, затем сохраним его на той стороне в файл:
sudo dd if=/dev/sda | ssh user@host "dd of=sda.img"
Теперь чтобы восстановить состояние диска из сделанной копии выполните:
ssh user@host "dd if=sda.img" | dd of=/dev/sda
Здесь и выше /dev/sda имя файла вашего жесткого диска.
Использование ssh пароля для входа на сервер не только неудобно но и небезопасно, потому что этот пароль в любой момент может быть подобран. Самый надежный и часто используемый способ аутентификации - с помощью пары ключей RSA. Секретный ключ хранится на компьютере, а публичный используется на сервере для удостоверения пользователя.
Настроить такое поведение очень легко. Сначала создайте ключ командой:
ssh-keygen -t rsa
Во время создания ключа нужно будет ответить на несколько вопросов, расположение оставляйте по умолчанию, если хотите подключаться без пароля - поле Passphare тоже оставьте пустым.
Затем отправляем ключ на сервер:
ssh-copy-id -i ~/.ssh/id_rsa.pub user@host
Напомню, что хранить пароли в обычных текстовых файлах небезопасно, но если хотите, то да - возможно. Для этого используется оператор перенаправления ввода Bash:
ssh user@host < local_file.txt
При входе по ssh может выводиться приветствие, изменить его очень легко. За это отвечает файл /etc/issue. Просто откройте этот файл и введите нужный текст:
Хотите посмотреть были ли попытки неудачного доступа по ssh к вашему серверу и с каких IP адресов? Запросто, все запросы логируются в файл /var/log/secure, отфильтруем только нужные данные командой:
cat /var/log/secure | grep "Failed password for"
Кроме выполнения команд, можно копировать файлы по ssh. Для этого используется утилита scp. Просто укажите файл, который нужно передать, удаленный сервер и папку на сервере, вот:
$ scp /адрес/локального/файла пользователь@ хост: адерс/папки
Например:
scp ~/test.txt user@host:documents
Кроме утилиты scp, передача файлов ssh может быть выполнена более хитрым способом. Прочитаем файл и с помощью cat, передадим, а там сохраним поток в файл:
cat localfile | ssh user@host "cat > remotefile"
ssh user@host "cat > remotefile" < localfile
tar czf - /home/user/file | ssh user@host tar -xvzf -C /home/remoteuser/
Такое копирование файлов ssh позволяет отправлять сразу целые папки.
Если вам нужно запустить то или иное графическое приложение на удаленной машине необязательно для этого использовать VNC, вы можете обойтись возможностями ssh. Программа будет выполняться на стороне сервера, а вам будет лишь транслироваться окно, чтобы вы могли сделать все что нужно. Причем все данные шифруются. Чтобы эта функция работала, нужно включить ее поддержку на стороне сервера.
Затем просто выполняем команду запуска графического приложения на удаленном сервере вот таким образом:
ssh -XC user@remotehost "eclipse"
Как вы уже видели опция X разрешает перенаправление X11 на стороне клиента, а С - сжатие данных.
Если вы использовали ssh с нестабильным интернетом, когда соединение время от времени рвется, то вам уже, наверное, надоело закрывать терминал, потому что иначе, на первый взгляд, сеанс никак не прекратить. Когда соединение с удаленным сервером разорвано вы не можете ввести никакую команду и сочетания клавиш Ctrl+C, Ctrl+Z, Ctrl+D не работают. И не будут работать поскольку клиент пытается отправить эти команды на сервер. Но есть решение - Escape последовательности. Чтобы активировать их поддержку добавьте строку:
В файл /etc/ssh/ssh_config
Этот документ поможет Вам выполнить подключение к Вашему виртуальному серверу по протоколам SSH и SFTP.
SSH (англ. Secure SHell - «безопасная оболочка») - сетевой протокол сеансового уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов). Сходен по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли.
SFTP (англ. SSH File Transfer Protocol) - протокол прикладного уровня, предназначенный для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Существует заблуждение, что SFTP это просто обычный FTP, работающий поверх SSH. В действительности SFTP - это новый протокол, разработанный с нуля.
Все данные, необходимые для подключения к Вашему виртуальному серверу по SSH, Вы можете получить на главной странице панели управления .
Нам необходимо знать IP адрес виртуального сервера (1) и пароль для пользователя root (2).
Получив необходимые данные для подключения, можно приступать непосредственно к процессу.
Пользователи операционных систем Mac OS X или Linux могут использовать стандартное приложение terminal для подключения к виртуальному серверу по SSH протоколу. Для подключения к Вашему виртуальному серверу используйте следующую команду (измените 188.127.236.62 на IP адрес вашего виртуального сервера):
Так выглядит процесс подключения к виртуальному серверу в терминале Unix или Mac OS X:
Ssh [email protected] The authenticity of host "188.127.236.62 (188.127.236.62)" can"t be established. RSA key fingerprint is 4f:e8:84:42:51:80:48:70:45:6c:69:47:79:e7:c0:56. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added "188.127.236.62" (RSA) to the list of known hosts. [email protected]"s password: #
Пользователи операционной системы Windows могут использовать для соединения с виртуальным сервером по протоколу SSH программу PuTTY. PuTTY - очень популярный telnet/ssh клиент, распространяется бесплатно.
Официальный сайт программы - http://www.chiark.greenend.org.uk/~sgtatham/putty/ Русскоязычный сайт поддержки - http://putty.org.ru/
После запуска программы вы увидите следущее окно:
Введите в поле “Host Name (or IP address)” IP-адрес Вашего виртуального сервера (на примере вводится helios.asu). Убедитесь, чтобы в пункте “Protocol” была выбрана радио-кнорка “SSH”.
Также, для того, чтобы каждый раз не вводить адресс и тип протокола вы можете сохранить сессию. Для этого введите ее название в поле “Saved Sessions” и нажмите кнопку “Save”.
После этого ваша сессия появится ниже в списке. Для того чтобы загрузить сохраненную сессию нужно выбрать ее из списка и нажать кнопку “Load”.
Для подключения нажмите кнопку “Open” внизу формы. Может появиться следующее сообщение:
Если вы уверены в том, что подключаетесь к нужному хосту, то нажмите кнопку “Yes/Да”. Появится следующее:
Введите свой логин (root), затем пароль. Перед вами консоль системы:
Для выхода введите:
По умолчанию вам не нужно настраивать FileZilla, мы просто сразу начнём работать с программой.
Для того, чтобы подключиться к SFTP-серверу, введите IP-адрес вашего виртуального сервера в поле быстрого подключения (вместо example.com, как показано на рисунке ниже введите sftp://ip_адрес_вашего_vps). Введите порт подключения в соответствующее поле, для SFTP - 22. Введите имя пользователя и пароль, в соответствующие поля. Нажмите на кнопку “Быстрое соединение” или нажмите Enter для подключения.
Отметим, что панель быстрого подключения, как ясно из названия, приспособлена для быстрых подключений, т.е. у вас нет возможности редактировать список из 10-ти последних подключений. Для сохранения параметров подключения используйте Менеджер Сайтов.
Используйте Менеджер сайтов FileZilla для задания определённых параметров сайта и подключения к нужному SFTP-серверу. В Менеджере сайтов у вас есть возможность сохранять свои подключения и настраивать большее число параметров, чем доступно в панели быстрого подключения.
После подключения, в правой стороне главного окна будет отображён список файлов и директорий. Текущая директория будет показана в редактируемом поле в верхней части. Ниже отображается удалённое дерево директорий, а ещё ниже - содержимое текущей удалённой директории. Перейти в другую директорию можно тремя разными путями. Первый: сделайте двойной щелчок на директории в списке. Второй: кликните на директории в дереве. Последний способ: введите имя директории в редактируемое поле и нажмите Enter. Обратите внимание на директорию “..”, присутствующую практически во всех остальных директориях. Эта ссылка позволяет вам перейти к родительскому каталогу текущей директории.
Навигация на вашем компьютере работает почти так же, как и на сервере. Текущая локальная директория и дерево каталогов по умолчанию отображаются на левой стороне главного окна.
Подробную документацию по работе с FileZilla, Вы можете найти на официальном сайте по адресу http://filezilla.ru/documentation/Using
Материал представленный на данной странице может быть использован Вами по своему усмотрению. Разрешается копирование и распространение предоставленного материала без изменения содержания и без предварительного уведомления администрации Clodo.ru .
Мы будем признательны Вам за сообщения об ошибках в представленной документации и за предложения об улучшении документации. По этим вопросам необходимо обращаться по адресу [email protected] . При обращении не забывайте указывать URL-адрес публикации.
abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Оглавление:
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Сменить пароль на ключ можно с помощью команды ssh-keygen -p .
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id "-p 443 user@server" (внимание на кавычки).
Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся - это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль - то паранойю можно включать на 100% и пароль не вводить).
Удалить известный ключ сервера можно командой ssh-keygen -R server . При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 .
Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key
и /etc/ssh/ssh_host_rsa_key.pub
. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.
Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.
Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.
Scp path/myfile [email protected]:/full/path/to/new/location/
Обратно тоже можно:
scp [email protected]:/full/path/to/file /path/to/put/here
Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб - предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» - и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
Так тоже можно:
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере - с него в этой статье показываются картинки) на мой ноут:
#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user . Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет - авторизация по паролю выбешивает на 2-3 подключение.
Отключить обратно можно командой fusermount -u /path , однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.
Ssh user@server ls /etc/
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command
Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk "{print $2}" |local_app
Это нас приводит следующей фиче:
Ssh [email protected] command >my_file
Допустим, мы хотим локальный вывод положить удалённо
Mycommand |scp - [email protected]:/path/remote_file
Усложним пример - мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
Mycommand | ssh [email protected] «scp - [email protected]:/path/to/file»
Есть и вот такой головоломный приём использования pipe"а (любезно подсказали в комментариях в жж):
Tar -c * | ssh user@server "cd && tar -x"
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar - читает и распаковывает. Так сказать, scp для бедных.
В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh [email protected]. Каждый раз печатать - туннельных синдромов не напасёшься. В малых компаниях проблема обратная - никто не думает о DNS, и обращение на сервер выглядит так: ssh [email protected]. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 [email protected]. Удавиться. Про драму с scp даже рассказывать не хочется.
Можно прописать общесистемные alias"ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Host ric Hostname ооо-рога-и-копыта.рф User Администратор ForwardX11 yes Compression yes Host home Hostname myhome.dyndns.org User vasya PasswordAuthentication no
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Host * User root Compression yes
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd _config), но это требует прав рута и распространяется на всех пользователей.
Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу - не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).
Ключики: -X - проброс X-сервера. -Y проброс авторизации.
Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.
В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем , так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:
ssh ric
rdesktop -k en-us 192.168.1.1 -g 1900x1200
И чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает - его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server
В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай - если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.
Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение - повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
А вот кусок ~/.ssh/config с ноутбука, который описывает vpn
Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443
(обратите внимание на «ленивую» форму записи localhost - 127.1, это вполне себе законный метод написать 127.0.0.1)
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая - «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук - А, а «сервер» - Б.
Задача : у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
Ssh -R 127.1:80:8.8.8.8:8080 [email protected]
Опция -R
позволяет перенаправлять с удалённого (R
emote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача
. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost"у.
Итоговая конфигурация: запросы на localhost:3333 на "A" должны обслуживаться демоном на localhost:3128 "Б".
Ssh -L 127.1:3333:127.1:3128 [email protected]
Опция -L позволяет локальные обращения (L ocal) направлять на удалённый сервер.
Задача : На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
Ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]
Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected]
Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.
(сам я увы, таким не пользовался).
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели - либо ssh разрешён (читай - делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Повторю картинку:
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
Ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.
Вызов выглядит так:
Ssh -A [email protected] ssh [email protected]
Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод - он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет - взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её .
Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.
Выглядит это так (циферки для картинки выше):
Ssh/config:
Host raep
HostName 10.1.1.2
User user2
ProxyCommand ssh -W %h:%p [email protected]
Ну а подключение тривиально: ssh raep .
Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить - да, может. Но если разрешил - пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]
Разумеется, подключение можно оснащать всеми прочими фенечками - прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
туннелирование ssh
Добавить метки
SSH (Secure Shell) - это сетевой протокол удаленного доступа, использующий шифрование и сжатие для передаваемых данных. Проще говоря - это весьма полезный и мощный инструмент, позволяющий аутентифицироваться в системе и полноценно работать от имени локального пользователя, находясь за много километров от работающей машины. Также, в отличие от telnet и rsh - SSH шифрует весь трафик, так что вся переданная информация остается конфиденциальной.
Итак, ssh у нас уже установлен и ssh-daemon добавлен в автозагрузку при старте системы. Управлять им можно по команде:
service ssh stop|start|restart
В Ubuntu, или:
/etc/init.d/ssh {start|stop|reload|force-reload|restart|status}
В Debian, или:
systemctl start|stop|restart sshd.service
В ArchLinux (после каждой правки конфига нужно делать рестарт). В комплект входит клиент и сервер.
Опробуем в деле! Для начала создайте папку ~/.ssh
mkdir ~/.ssh
Сгенерируйте ключи для данного пользователя сервера командой:
ssh-keygen (от имени обычного пользователя).
При генерации, вы можете задать парольную фразу для ключа (желательно задать, и длинную - тогда даже заполучив ключ но не зная пароль от ключа, злоумышленник не сможет залогинится), а можете пропустить, просто нажав "Enter" - в таком случае, пароль никогда не спросится. В папке ~/.ssh появились те самые публичный и закрытый ключ.
Найдите ещё одну машину (даже смартфон подойдет - на Android есть несколько замечательных SSH-клиентов, вроде ConnectBot или JuiceSSH), установите на ней ssh и подключитесь к серверу командой:
ssh user@server
Если всё сделано правильно, будет запрошен пароль пользователя, и после ввода вы окажетесь в своей системе с видом из командной строки.
Для Windows, к слову, также есть сервера и клиенты ssh.
Насладившись результатом трудов своих, приступим к ещё более скучной части - настройке клиента/сервера.
Конфиг клиентской части лежит в /etc/ssh/ssh_config , а серверной - /etc/ssh/sshd_config . Наиболее полным руководством по настройке является, пожалуй, страница в man - man ssh и man sshd_config, так что рекомендуем прочититать её. А в данной статье рассмотрим наиболее необходимые вещи.
Стандартный порт ssh - 22. Его можно сменить на любой нестандартный (усложняя возможный взлом благодаря безопасности через неясность, или же для привлечения внимания потенциальных взломщиков:) - для этого расскомментируйте строчку:
#Port 22
И добавьте любой желаемый до 65535 (убедившись, что порт не конфликтует с другими сервисами командой #netstat -tupln | grep LISTEN ).
Теперь при подключении к серверу, клиенту потребуется писать с ключом:
ssh -p [порт] :
По умолчанию доступ от имени root разрешен. Крайне желательно ограничить его (и вместо этого правильно разграничить права локального пользователя с помощью sudo). Для этого найдите строчку "PermitRootLogin" и смените значение на "no". Можно также сменить на "without-password" - в таком случае, логин под рутом будет разрешен только из под машин с доверенным ключом.
Можно отключить аутентификацию по паролю и работать только с ключами - найдите строчку: "PasswordAuthentication" и смените значение на "no". Зачем? Если кто-то очень захочет получить доступ к вашей системе, то он сможет либо перебрать пароль при попытках авторизации, либо прослушать и расшифровать ваше соединение. Если отключить аутентификацию по паролю и добавить в ~/.ssh/authorized_keys на сервере публичный ключ своего, например, рабочего ноутбука, то, как мы помним, нас пустит на сервер сразу. Но как быть, если вы работаете на чужой машине и срочно нужно получить доступ на ssh-сервер, а он нас ожидаемо не пускает? Тогда можно не отключать парольную аутентификацию, а воспользоваться утилитой fail2ban. Просто установите её из вашего репозитория, после чего она применит настройки по умолчанию и, как минимум, защитит ваш ssh-канал от взлома методом перебора. Подробнее о fail2ban - http://putty.org.ru/articles/fail2ban-ssh.html.
На тот случай, если на вашем сервере хранятся ключи запуска ядерных ракет, то можно сделать как-то так:
PermitRootLogin no - запрещен логин под рутом.
PasswordAuthentication no - вход без пароля
Сгенерируем на удаленной машине длинный ключ (-t тип_шифрования, -b битовая длина):
ssh-keygen -t rsa -b 4096
С не менее сложной парольной фразой (восстановить забытый пароль, к слову, нельзя. Можно сменить его командой "ssh-keygen -p", но с вас в любом случае спросят старый). Перенесем публичный ключ удаленной локальной машины в ~/.ssh/authorized_keys сервера, и вуаля - теперь доступ можно получить с единственной машины, с помощью парольной фразы зыкрытого ключа. SSH позволяет настроить множество конфигураций безопасности и имеет для этого множество специфичных настроек - о них читайте в man.
Этим же целям служат два параметра sshd_config:
LoginGraceTime - задает время, по истечении которого будет разорвано соединение, если не произойдет аутентификация.
MaxAuthTries - задает количество неверных попыток ввода логина, по достижении которого соединение будет разорвано.
MaxSessions - количество одновременных сессий (если сервер - ваш домашний компьютер, к которому вы собираетесь подключаться из универа или с работы, то разумно будет ограничить число сессий до одной - отклоненный логин, в таком случае, станет поводом для повышения паранойи, генерации новых ключей и смены пароля). Впрочем, если вы внимательны, то могли заметить, что при каждом логине на сервер высвечивается строчка "Last Login". Помимо неё, можно добавить собственное приветственное сообщение - найдите строчку "Banner" и вместо none задайте путь к файлу с текстом, который будет прочитан и выведен при логине.
Помимо прочего, можно разрешить вход в систему только определенным пользователям, или разрешить всем, помимо определенных пользователей:
AllowUsers user1 - разрешить вход только user1.
DenyUsers user1 - разрешить всем, кроме user1.
И аналогичные параметры для доступа определенных групп - AllowGroups и DenyGroups.
Также по SSH можно передавать сеанс X11. Для этого найдите строчку "ForwardX11" и измените значение на "yes".
Аналогичную строку найдите в конфиге клиента - /etc/ssh/ssh_config, и также смените на "yes".
Теперь присоединяться к серверу по ssh нужно с аргументом -X:
ssh -X user@server>
Можно сразу запуcтить приложение при коннекте:
ssh -X user@server "приложение"
Вот так выглядит работающий GIMP в ssh-сессии:
Или можно получить вывод с веб-камеры ноутбука ничего не подозревающего пользователя:)
Вычисления производятся непосредственно на сервере, а вывод передается на клиентскую машину (то есть, даже если на самом сервере не стоят X11, графические приложения можно отрисовывать на вашей удаленной машине). Работает такая схема довольно медленно (не забываем, что весь трафик динамически шифруется) - но функция эта весьма полезна.
По SSH-сессии можно также копировать файлы - для этого есть простенькая утилита "scp". Передавать файлы можно прямо в сессии как с сервера на клиент:
scp user@server:/путь/к/файлу/на/сервере /куда/сохранить/на/локальной/машине
Так и с клиента на сервер:
scp путь/к/файлу/клиента user@server:/путь/на/сервере
Это достаточно удобно, если нужно скопировать текстовик или фотографию, но как быть, когда предстоит работа с многими файлами? Для этого существует удобнейшая вещь - sshfs (доступна для установки в репозиториях большинства *nix-систем).
Просто задайте путь аналогично scp:
sshfs user@server:/home/user /mnt/
И папка /home/user сервера появится в точке монтирования /mnt локальной машины!
Отмонтирование производится через umount.
И, напоследок, расскажем об одной малоизвестной фиче. Если создать файл /.ssh/config и заполнить его подобным образом:
Host [имя]
Hostname
User [имя пользователя сервера]
желаемые опции
вроде
ForwardX11 yes
Port 30000
То можно будем логиниться по:
ssh [имя]
ssh -X -p 30000 user@server
И все опции подхватятся автоматически. Таким образом, при частой аутентификации на определенном сервере, вы упростите этот процесс к делу пары мгновений.
Что ж, мы рассмотрели всё (и даже больше) что нужно знать об SSH, для его бытового использования - научились пользоваться аутентификацией по ключу, защитили сервер от взлома перебором и в целом, наложили заплатки на большинство потенциальных дыр. На самом деле, SSH может ещё много разных штук - например, туннелирование и проброс портов через ssh-сессию, но вряд ли вы, как самый обычный пользователь, когда-либо этим воспользуетесь. Дополнительные ресурсы