Ssh root что это
Настройка SSH подключения к серверу
Данное руководство научит создавать SSH-подключения к серверу Linux и управлять ими.
SSH (Secure Shell) – это криптографический сетевой протокол, который используется, среди прочего, для удаленного входа и выполнения команд. Это стандартный метод удалённого доступа и взаимодействия с серверами Linux.
Требования
Для выполнения руководства понадобится:
Создание SSH-подключения root
Примечание: Следуйте инструкциям подраздела, предназначенного для выбранного вами SSH-клиента.
1: OpenSSH
Клиент OpenSSH – это инструмент командной строки. Для начала откройте окно терминала.
Инициирование соединения
Чтобы подключиться к серверу как root, в командной строке введите следующую команду:
Примечание: В команде укажите IP-адрес сервера.
К примеру, если IP-сервера 111.222.333.444, то команда должна выглядеть так:
При первом подключении к серверу вы, вероятно, получите предупреждение:
The authenticity of host ‘123.123.123.123 (123.123.123.123)’ can’t be established.
ECDSA key fingerprint is
79:95:46:1a:ab:37:11:8e:86:54:36:38:bb:3c:fa:c0.
Are you sure you want to continue connecting (yes/no)?
Так компьютер сообщает, что удалённый сервер не идентифицирован. Чтобы продолжить, введите yes.
Если перед созданием текущего сервера вы случайно уничтожили другой сервер, на экране может появиться такое предупреждение:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
.
В таком случае новый сервер, вероятно, имеет такой же IP, что и старый, уничтоженный сервер, но использует другой SSH-ключ. Это нормальное поведение. Чтобы устранить это предупреждение, удалите ключ хоста предыдущего сервера из системы при помощи команды:
После этого попробуйте подключиться снова.
Аутентификация
Для аутентификации нужно предоставить учётные данные (имя пользователя, пароль и/или ключ SSH).
Если на сервер установлен SSH-ключ и закрытый ключ добавлен на компьютер, OpenSSH попробует использовать для аутентификации эти ключи. Если ключи защищены паролем, система запросит этот пароль. Если войти не получается, возможно, нужно запустить ssh-agent и добавить ключи SSH при помощи этой команды, а затем повторить раздел 1 (в руководстве ключ условно называется id_rsa):
Если сервер не защищён ключами SSH, программа запросит временный пароль, который позже следует изменить. Чтобы завершить процесс входа, выполните следующие действия:
Теперь при входе будет использоваться новый пароль.
2: PuTTY
Дважды кликните на файл putty.exe, чтобы запустить программу и открыть окно настройки.
Настройка соединения
Сначала нужно правильно настроить соединение. Для этого установите следующие параметры:
После этого можно выбрать имя и сохранить текущее соединение для дальнейшего использования; для этого введите имя в поле Saved Sessions и нажмите Save.
Инициирование соединения
Чтобы инициировать соединение, дважды кликните на имени сессии и примите предупреждение системы безопасности (оно появится только при первом подключении к серверу).
Аутентификация
Теперь нужно предоставить учётные данные (имя пользователя и временный пароль, который нужно изменить сразу после подключения к серверу).
Чтобы пройти аутентификацию:
Дальнейшие рекомендации
Подключившись к серверу, нужно выполнить его начальную настройку. Полезные инструкции можно найти в следующих руководствах:
Как пользоваться SSH
В этой инструкции мы рассмотрим как пользоваться ssh, а также ее возможности, о которых вы даже не знали. Скорее всего, вы уже знаете как подключиться к серверу по ssh, но у этой утилиты есть еще много возможностей, таких как передача файлов ssh, подключение без пароля или выполнение скрипта на удаленном сервере. Все это мы и рассмотрим далее в статье. Но начнем с самых основ.
Базовый синтаксис
Синтаксис команды выглядит следующим образом:
$ ssh [опции] имя пользователя @ сервер [команда]
Важно заметить что ssh может работать по двум версиям протокола. Версии 1 и 2. Понятное дело, что версия 2 лучше и поддерживает больше типов шифрования и аутентификации. Больше в этой статье об отличиях протоколов мы говорить не будем и я буду подразумевать что вы используете версию 2.
Опции команды SSH
Теперь давайте рассмотрим самые основные опции команды ssh:
Это далеко не все опции утилиты, остальные выходят за рамки данной статьи. Многие настройки работы ssh можно изменять через конфигурационный файл
/.ssh/config но здесь мы это тоже подробно рассматривать не будем.
Настройка сервера SSH
Настройки сервера SSH находятся в файле /etc/ssh/sshd_config. Многие из них мы тоже трогать не будем. Рассмотрим только самые интересные. Сначала откройте файл /etc/ssh/sshd.conf
Порт ssh
По умолчанию ssh работает на порту 22. Но такое поведение небезопасно, поскольку злоумышленник знает этот порт и может попробовать выполнить Bruteforce атаку для перебора пароля. Порт задается строчкой:
Поменяйте значение порта на нужное.
Протокол SSH
По умолчанию сервер ssh может работать по двум версиям протокола, для совместимости. Чтобы использовать только протокол версии два раскомментируйте строчку:
И приведите ее к такому виду:
Рут доступ
По умолчанию Root доступ по ssh разрешен, но такое поведение очень небезопасно, поэтому раскомментируйте строчку:
Доступ только определенного пользователя к SSH
Мы можем разрешить доступ к ssh только для определенного пользователя или группы. Для этого добавьте строчки:
AllowUsers User1, User2, User3
AllowGroups Group1, Group2, Group3
Выполнение X11 приложений
Не все знают но есть возможность использовать ssh для запуска полноценных X11 приложений. Об этом мы поговорим ниже, но чтобы все заработало необходимо разрешить эту возможность на стороне сервера, добавьте такую строчку:
Основные опции рассмотрели, перед тем как переходить дальше, не забудьте перезагрузить ssh сервер чтобы сохранить изменения:
service sshd restart
Использование SSH
Подключение к серверу
Чтобы просто подключиться к серверу по SSH используйте такую команду:
Выполнить команду
Мы привыкли подключаться к удаленному серверу, а уже потом выполнять нужные команды, но на самом деле утилита ssh позволяет сразу выполнить нужную команду без открытия терминала удаленной машины. Например:
Выполнит команду ls на удаленном сервере и вернет ее вывод в текущий терминал.
Выполнить локальный скрипт
Выполним интерпретатор bash на удаленном сервере и передадим ему наш локальный скрипт с помощью перенаправления ввода Bash:
Бекап на удаленный сервер и восстановление
Мы можем сохранять бекэп диска сразу на удаленном сервере с помощью 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.
Взять пароль из локального файла
Изменить приветствие SSH
При входе по ssh может выводиться приветствие, изменить его очень легко. За это отвечает файл /etc/issue. Просто откройте этот файл и введите нужный текст:
Смотрим неудачные попытки входа SSH
Хотите посмотреть были ли попытки неудачного доступа по ssh к вашему серверу и с каких IP адресов? Запросто, все запросы логируются в файл /var/log/secure, отфильтруем только нужные данные командой:
cat /var/log/secure | grep «Failed password for»
Передача файлов по SSH
Кроме выполнения команд, можно копировать файлы по ssh. Для этого используется утилита scp. Просто укажите файл, который нужно передать, удаленный сервер и папку на сервере, вот:
$ scp /адрес/локального/файла пользователь@ хост: адрес/папки
Кроме утилиты scp, передача файлов ssh может быть выполнена более хитрым способом. Прочитаем файл и с помощью cat, передадим, а там сохраним поток в файл:
cat localfile | ssh user@host «cat > remotefile»
ssh user@host «cat > remotefile»
Пойдем еще дальше, вы можете сжимать файлы перед передачей с помощью tar, а потом их сразу же на лету распаковывать:
Такое копирование файлов ssh позволяет отправлять сразу целые папки.
Запуск графических приложений по ssh
Если вам нужно запустить то или иное графическое приложение на удаленной машине необязательно для этого использовать VNC, вы можете обойтись возможностями ssh. Программа будет выполняться на стороне сервера, а вам будет лишь транслироваться окно, чтобы вы могли сделать все что нужно. Причем все данные шифруются. Чтобы эта функция работала, нужно включить ее поддержку на стороне сервера.
Затем просто выполняем команду запуска графического приложения на удаленном сервере вот таким образом:
Завершение сессии SSH
В файл /etc/ssh/ssh_config. Теперь, чтобы разорвать SSH соединение достаточно нажать Enter и набрать:
Другие управляющие символы можно узнать нажав:
Туннели SSH
С помощью SSH туннелей вы можете пробросить порт с удалённого сервера на локальную машину. Это очень полезно, в первую очередь, для разработчиков. Для того чтобы пробросить порт с удалённой машины локальной используйте опцию -L и такой синтаксис:
Например, сделаем удалённую базу данных доступной локально на порту 5555. Для этого выполните подставив свои значения:
Теперь локальная база данных на порту 3306 будет доступна на удалённом сервере при обращении к порту 5555.
Выводы
Теперь вы знаете как пользоваться SSH. Как видите, технология SSH позволяет сделать намного больше чем можно предположить с первого взгляда, и это еще далеко не все. Какие интересные возможности SSH используете вы при повседневной работе? Поделитесь в комментариях!
Как включить root-вход по SSH в Linux
от sasza
SSH великолепен, так как дает пользователям Linux простой консольный доступ к любому компьютеру по сети. Один из способов улучшить работу с SSH в Linux — включить SSH-вход с правами root. С помощью этого параметра легко быстро войти непосредственно в учетную запись Root для выполнения задач системного уровня.
По умолчанию в SSH root не включен из соображений безопасности. Однако, если вы управляете большим количеством систем и вам нужен постоянный root-доступ для выполнения скриптов, автоматизации и т. Д., Включение этой функции является обязательным.
Чтобы было ясно, включение входа в систему Root через SSH опасно. Не делайте этого, если вы новичок в SSH!
Пароль root
Первым шагом к включению входа в систему с правами root через SSH является включение учетной записи Root. Для многих дистрибутивов Linux (Ubuntu и ему подобных) Root не активен в целях безопасности. Вместо этого пользователи делают все через привилегии sudo. По большей части не использовать учетную запись Root — это нормально, и sudo справится с этой задачей. Однако при использовании SSH пользователям необходимо знать пароль root.
Сначала войдите на свой удаленный сервер / ПК, на котором вы хотите удаленно включить Root over SSH:
Если вы настроили свой дистрибутив Linux и не настраивали пользователя Root, вам необходимо выполнить следующие шаги, чтобы настроить Root. Пожалуйста, поймите, что этот процесс не будет работать без пользователя, который может использовать sudo. Для начала откройте терминал. В терминале запустите:
Запуск passwd предложит пользователю указать «новый пароль UNIX». Введите новый пароль для учетной записи Root на вашем ПК. В целях безопасности не используйте тот же пароль для Root, что и для вашей обычной учетной записи. Обязательно создайте безопасный, но запоминающийся пароль для учетной записи.
После установки пароля выйдите из оболочки Root с помощью exit.
Наконец, убедитесь, что новый пароль Root работает, войдя в него через su.
Включить вход в систему с правами root
Теперь, когда мы знаем, что можно войти в систему как пользователь root, пришло время включить параметр входа в систему Root в файле конфигурации SSHD. Еще раз, начните с открытия терминала и подключения через SSH как обычный пользователь.
Примечание. Не хотите удаленно изменять свой SSH-сервер? Измените его локально, а не в терминале.
Мы подключены (удаленно) через SSH к серверу SSH. Затем повысите обычное соединение до Root-доступа, войдя в систему через su.
Затем, используя текстовый редактор Nano, откройте файл конфигурации SSH-сервера.
Просмотрите файл конфигурации, найдите «PermitRootLogin». Перед ним может стоять «нет». В этом случае измените «нет» на «да».
В других случаях SSH «PermitRootLogin» может сказать «запретить пароль». Удалите «запретить-пароль» и измените его на «да».
После изменения настроек Root для SSH-сервера вам необходимо сохранить изменения конфигурации. Изменения конфигурации сохраняются в Nano при нажатии комбинации клавиш Ctrl + O. Закройте редактор Nano, нажав Ctrl + X, когда конфигурация сохранится правильно.
Применение корневых настроек
Теперь, когда в настройках включен вход в систему с правами root, вам необходимо перезапустить демон SSH, чтобы применить изменения. На большинстве компьютеров с Linux это легко сделать с помощью systemd. В терминале получите root-доступ с помощью su или sudo:
После получения root используйте systemd для перезапуска демона SSH.
Не использовать systemd? Вместо этого попробуйте эту команду:
Если ни одна из команд не работает для перезапуска демона SSH, надежный способ — просто перезапустить сервер, на котором запущен SSH:
После перезагрузки изменения должны быть применены. Чтобы войти в систему как root, откройте терминал и попробуйте следующее:
Отключить root-вход
Больше не хотите входить в систему через SSH? К счастью, эту функцию так же легко отключить, как и включить. Первый способ — просто заблокировать учетную запись Root. Выполнение этого способа позволяет включать и выключать параметр на лету, разблокировав учетную запись Root. Чтобы заблокировать Root, получите оболочку суперпользователя через sudo и запустите:
Эта команда шифрует учетную запись root и фактически отключает ее. Чтобы вернуть его для использования с Root over SSH, следуйте инструкциям в верхней части статьи.
В качестве альтернативы, чтобы полностью отключить вход в систему Root, откройте терминал (с Root):
В файле конфигурации SSH найдите «PermitRootLogin» и измените его с «да» на «нет».
Нажмите Ctrl + O, чтобы сохранить, выйдите, нажав Ctrl + X, а затем перезагрузитесь. После сброса вход в систему Root работать не будет.
Как подключиться к серверу по SSH с помощью пароля или ключа
SSH — зашифрованный протокол для удаленного управления серверами. Для подключения через него вы можете каждый раз вводить пароль или настроить авторизацию по ключу. Второй вариант безопаснее, но у него есть свои особенности. В этой статье мы рассмотрим оба метода подключения, а вы уже сами выберите, какой способ удобнее.
Проверка службы SSH на сервере
Доступ по SSH обычно можно включить при создании сервера или во время настройки конфигурации. Убедиться в том, что он разрешен, можно через консоль. Она доступна в панели управления сервером.
Например, у меня VDS на Timeweb. Чтобы попасть в консоль, я авторизуюсь по логину и паролю, выданному хостером, выбираю свой сервер в списке VDS и перехожу на вкладку «Консоль».
Чтобы пользоваться консолью, нужно авторизоваться. Логин и пароль для доступа к серверу хостер присылает в письме. Сначала нужно ввести логин и нажать на клавишу Enter. Появится строка Password. В ней необходимо ввести пароль и снова нажать на клавишу Enter.
Важно: в целях безопасности при вводе пароля на экране не отображаются никакие символы, даже привычные звездочки.
После авторизации в консоли можно проверить, запущена ли служба SSH на сервере.
Если служба не активна, добавьте ее самостоятельно. Выполните команду sudo apt install openssh-server и подтвердите установку пакетов.
Кроме того, для подключения вам может понадобиться настройка брандмауэра. Чтобы межсетевой экран не блокировал входящие соединения, можно на время отключить его командой sudo ufw disable.
Использование пароля
Начнем с инструкции о том, как подключиться к удаленному серверу через SSH по логину и паролю. Это самый простой способ. Хостер предоставляет вам IP-адрес, логин и пароль. Этого достаточно для того, чтобы установить соединение с удаленным сервером.
Подключение на Windows
Моя основная система — Windows. Раньше для подключения к серверу через SSH я пользовался сторонней утилитой PuTTY, потому что в операционной системе не было встроенного компонента. В «десятке» он появился, так что теперь можно подключаться к SSH через командную строку (cmd).
Чтобы включить встроенный в систему OpenSSH:
Теперь разберемся, как подключиться к SSH через cmd. Запустите командную строку и выполните запрос вида ssh root@185.104.114.90.
После выполнения команды клиент SSH предложит добавить устройство в список известных. Введите в командной строке yes и нажмите на Enter. Затем укажите пароль для доступа к серверу. На этом подключение к серверу через SSH завершено — теперь все команды будут выполняться на удаленной машине, к которой вы подключились.
На версиях младше Windows 10 1809 нет встроенной поддержки протокола OpenSSH. В таком случае понадобится сторонняя утилита. Смотрим, как через PuTTY подключиться по SSH:
Если вы ввели правильные данные, появится окно консоли, в котором нужно указать логин и пароль для подключения к серверу. При первом запуске также отобразится запрос на добавление устройства в список известных.
Подключение на Linux и macOS
Теперь посмотрим, как подключиться по SSH через терминал на Linux. Для этого не требуется установка дополнительных компонентов, все работает «из коробки».
На этом подключение завершено. Теперь все команды, которые вы вводите в терминале, будут выполняться на удаленной машине.
Если IP-адрес или порт указаны неверно, то на экране появится сообщение об ошибке — Connection Refused. Это может также говорить о том, что доступ запрещен брандмауэром на удаленном сервере (если вы его не отключили). Чтобы разрешить подключение через SSH:
Цифра 22 в синтаксисе — номер порта. Если вы используете другой порт, то укажите его явно.
Памятка пользователям ssh
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Управление ключами
Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).
Генерация ключа
Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Структура ключа
/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).
Копирование ключа на сервер
/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id ‘-p 443 user@server’ (внимание на кавычки).
Ключ сервера
/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).
Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).
Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.
Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.
Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.
Копирование файлов
Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.
scp path/myfile user@8.8.8.8:/full/path/to/new/location/
Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here
Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал
5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
sshfs
Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.
Удалённое исполнение кода
ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:
ssh user@server ls /etc/
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Это нас приводит следующей фиче:
Проброс stdin/out
Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл
ssh user@8.8.8.8 command >my_file
Допустим, мы хотим локальный вывод положить удалённо
mycommand |scp — user@8.8.8.8:/path/remote_file
Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»
Есть и вот такой головоломный приём использования pipe’а (любезно подсказали в комментариях в жж):
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.
Алиасы
Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.
Можно прописать общесистемные alias’ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Опции по умолчанию
По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.
Проброс X-сервера
Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.
и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Socks-proxy
Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
/.ssh/config с ноутбука, который описывает vpn
(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)
Проброс портов
Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.
Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.
Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.
Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.
Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
Вложенные туннели
Разумеется, туннели можно перенаправлять.
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Реверс-сокс-прокси
Туннелирование
Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.
(сам я увы, таким не пользовался).
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
Проброс авторизации
Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Для начала о простом пробросе авторизации.
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
Вызов выглядит так:
Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её redrampage.
Выглядит это так (циферки для картинки выше):
Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2
Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.