В этой статье мы рассмотрим современные и удобные способы работы с сервером по SSH с VPS от Infobox и облаком .

Мы расскажем не только про обычный способ подключения, но и про организацию устойчивого соединения через нестабильный интернет (например 3G модемы), а также о дополнительных утилитах, помогающих в работе по SSH.

Если вы пользователь Windows и вам нужно просто и быстро подключиться к Linux–серверу - переходите в раздел «Putty или как быстро подключиться к SSH из Windows».

Что необходимо знать для подключения по SSH

Для подключение необходимы:

• IP адрес сервера
• логин
• пароль

Где взять данные для подключения к серверу VPS NG от Infobox

После заказа услуги войдите в панель управления https://panel.infobox.ru .
Выберите услугу «VPS NG» в правом верхнем углу панели управления в выпадающем списке.
Затем перейдите во вкладку «VPS».

В этом разделе вы увидите ip-адрес сервера и можете установить пароль для доступа к серверу .

Для подключения используйте имя пользователя root , ip–адрес с этой страницы и установленный пароль .
Если вы забыли пароль, нажмите на пункт «Редактировать параметры доступа», показанном на скриншоте выше.

Где взять данные для подключения к серверу VPS от Infobox

Войдите в панель управления https://panel.infobox.ru .
Выберите услугу VPS в правом верхнем углу панели управления в выпадающем списке (в названии услуга содержит имя заказанной ОС и регион размещения).

Затем перейдите во вкладку «Управление VPS».

Используйте имя пользователя root , пароль и ip–адрес сервера с этой страницы.

Где взять данные для подключения к серверу InfoboxCloud

После создания сервера данные для подключения придут к вам на электронную почту. Этого достаточно для подключения.

Если вы потеряли письмо с данными для доступа и хотите получить доступ к серверу

По-умолчанию логин администратора сервера: root

Войдите в панель управления по адресу: https://panel.infobox.ru .
Выберите услугу «Облачные серверы» в правом верхнем углу панели управления в выпадающем списке.

Выделенный IP–адрес для сервера можно посмотреть во вкладке «Облачная инфраструктура» панели управления.

Если поле "Выделенный IP адрес " пустое, значит при создании сервера вы не добавили серверу хотя бы 1 выделенный ip–адрес (и следовательно доступа через Интернет к серверу нет, есть только из локальной сети).

Чтобы добавить выделенный IP–адрес, нажмите на имя сервера.

В группе настроек «Сеть» нажмите «Настроить».

Убедитесь, что пропускная способность (скорость) сети достаточна (или поставьте больше при необходимости).
Затем нажмите «Добавить IPv4–адрес» и нажмите «Сохранить изменения».

Теперь у сервера есть выделенный IP–адрес.

Для изменения пароля доступа к серверу нажмите «Изменить», как показано на скриншоте выше. Так вы можете установить пароль для доступа к серверу.
Теперь вы знаете ip–адрес сервера , логин (root ) и пароль .

Настройка SSH–клиентов

Для Windows

Для подключения к серверу вам потребуется SSH–клиент. Если необходимо быстро подключиться - рекомендуется Putty . Если требуется работа с unix–утилитами, такими как scp, rsync и ssh-copy-id – используйте Cygwin .

Putty или как быстро подключиться к SSH из Windows

Скачайте инсталлятор Putty для Windows из раздела The latest release version и установите Putty с настройками по-умолчанию.

Запустите Putty (Пуск -> Все приложения -> PuTTY -> PuTTY).

Введите IP–адрес сервера. Убедитесь, что выбран порт 22, а тип подключения SSH и нажмите «Open».

Вам будет задан вопрос, доверяете ли вы серверу, к которому подключаетесь. Нужно ответить «Да».

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

Подключение было успешно установлено.

Cygwin или Unix–окружение на вашем Windows компьютере

Работая с Linux–серверами вам может понадобиться подобное окружение на вашем компьютере. Использовать единый набор утилит на сервере и рабочем компьютере очень удобно, поэтому обязательно попробуйте Cygwin. Linux только с первого взгляда кажется сложным. Постепенно осваивая эту ОС вы все больше будете нуждаться в Cygwin. Хорошее затягивает.

Нестабильное интернет-соединение при подключении по SSH – что делать?

Часто, работая через нестабильную сеть (например через мобильный интернет 3G/4G или различные точки доступа WiFi) соединение с SSH обрывается. Давайте посмотрим, что можно сделать на уровне клиента, чтобы предотвратить необходимость переподключения. Данные инструменты не подходят для выполнения критически важных операций на сервере (например апгрейд ОС). Для выполнения критически важных операций нужно дополнительно использовать утилиты, описанные в следующем разделе статьи. Предназначение утилит в этом разделе - более удобная работа по SSH для пользователя.

AutoSSH

AutoSSH запускает копию ssh–клиента и осуществляет мониторинг за соединением, перезапуская ssh–клиент при необходимости.

Autossh использует ssh для построения петли ssh–перенаправлений (соединение с локального компьютера на удаленный и в обратном направлении) и пересылает тестовые данные, ожидая, что они вернутся назад. Также поддерживается использование удаленного эхо-сервиса для отправки назад тестовых данных.

AutoSSH поддерживает только 3 параметра:

• -M <порт>[: эхо-порт] - используется для указания порта мониторинга или порта мониторинга и порта эхо-сервиса. Если не указан порт эхо-сервиса, для него используется следующий по номеру порт. Например, если установлен флаг -M 20000, тестовые данные будут отправляться по порту 20000, а получаться по порту 20001. Если указать -M 0 – мониторинг соединения будет отключен и autossh будет перезапускать ssh только при выходе из ssh (можно использовать это с опциями ServerAliveInterval и ServerAliveCountMax в OpenSSH, если мониторинг в вашей ситуации не может быть использован);
• -f - отправляет autossh в фон еще до запуска ssh (пароль в таком режиме ввести вы не сможете);
• -V - отображает версию autossh.

Все остальные аргументы передаются как параметры ssh.

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

Установка AutoSSH в Cygwin в Windows

При использовании Cygwin в Windows введите:
apt-cyg update
apt-cyg install autossh

Теперь можно выполнить подключение к серверу:
autossh -M 20000 root@ip_адрес_сервера


Соединение успешно установлено.

В целом autossh – достаточно удобный инструмент для работы через нестабильные интернет-соединения и для организации ssh–туннелей на сервере (этот сценарий мы рассмотрим в отдельной статье). Недостаток autossh в том, что эта утилита не решает проблему, если в момент ввода команд на сети возникают значительные задержки (что в 3G сети случается). В этом случае вы будете ждать ответа от сервера на ввод каждого символа, что несколько замедляет работу. Тем не менее в обычных условиях работы autossh очень помогает поддерживать ssh–соединение.

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

Как выполнять критически важные и длительные операции на сервере: терминальные мультиплексоры

Если вы обновляете ОС, устанавливаете какое-то ПО или просто редактируете файл на сервере, после подключения через ssh или autossh не работайте напрямую. Если соединение по SSH будет разорвано - вы потеряете сессию, запущенную при подключении по SSH. Чтобы этого не произошло и при переподключении по SSH вы точно попали в продолжающуюся операцию на сервере или в открытое окно редактирования файла с того же момента, используйте на сервере терминальные мультиплексоры: GNU Screen или tmux .

GNU Screen

Изначально программа screen создавалась, чтобы запускать несколько терминальных сессий внутри одного терминала. Однако есть у screen и другое полезное свойство: возможность отсоединять виртуальные сеансы от физического терминала и подсоединять к другому. Это, в частности, позволяет запускать долгоиграющие процессы на удалённых машинах, без необходимости быть постоянно на них залогиненным.

1. Зайдите на удаленный сервер по SSH.
2. Запустите там screen
3. Вы увидите приветствие, нажмите Enter.
4. Теперь вы можете делать что угодно, как будто вы просто подключены к серверу по SSH (например запустите любой долгий процесс).
5. Вы можете отсоединить сессию, нажав CTRL + a, затем d. Можете даже завершить подключение по SSH к серверу.
6. Чтобы вернуться в сессию, переподключитесь по SSH (или это сделает autossh) и введите screen -r
Вы вернетесь в запущенную сессию, а в ней продолжается запущенный вами процесс ранее. Более подробно терминальные мультиплексоры мы разберем в последующих статьях.

Заключение

В этой статье мы попытались рассказать основы, необходимые для удобной работы по SSH из различных ОС. Конечно это далеко не все, что возможно, но хорошая база для начала. Если вы нашли ошибку в статье, считаете, что нужно добавить что-то важное или просто у вас есть вопрос -

В этой статье расскажем вам как установить SSH в Linux, Windows и Mac, как настроить и как пользоваться! Все до мелочей! Будет интересно!

SSH — это популярный протокол для удаленного управления (администрирования) операционных систем на ядре Linux, Unix. Для новичков Linux не совсем понятно установка данного протокола, настройка и использование, чтобы это исправить было решено написать данную статью!

Одной из самых популярных операционных систем работающих на ядре Linux является Ubuntu, поэтому объяснять о ssh будем именно на ней.

Сначала все действия мы объясним на примере с Linux, а после и в Mac и Windows!

Установка SSH в ОС Linux

В 99,99% случаях в Linux уже установлен ssh клиент, с помощью которого можно подключиться к удаленной машине. Но если вы хотите чтобы подключились к компьютеру за которым вы сейчас находитесь или на любой другой, необходимо «скачать ssh сервер».

Сделать это очень просто, все необходимое уже есть в репозиториях (а-ля магазин программ), откройте терминал и введите команду:

Sudo apt install openssh-server

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

Подключение по SSH (с паролем)

Откройте терминал и введите команду для подключения к удаленной машине:

Ssh ИмяПользователя @IPадрес

Вначале пишем ssh , потом имя пользователя который есть на удаленной машине, далее знак @ (собачка) и IP адрес. Вот например:

Ssh sasha@ 100.08.30.48

Как правило, ssh подключение происходит к порту 22, если вы его принудительно изменили, то нужно его указать. Для этого в конце пишем -p номер. Вот пример:

Ssh sasha@ 100.08.30.48 -p 3040

После того как вы подключились и если это было первое подключение к машине, вам необходимо будет, добавить машину в доверенные — напишите yes и нажмите Enter. Выполняется это один раз.

Создание SSH-ключа и подключение без пароля!

Для того чтобы не запоминать пароль и каждый раз его не вводить, особенно если у вас множество Linux серверов можно создать специальный SSH-ключ. Этот ключ позволит подключаться с уже «известной» машины с «известным» сервером, без использования пароля.

Как создать ключ SSH?

На компьютере за которым вы сейчас находитесь создаем ключ, а после, его необходимо будет скопировать на наш сервер!

Создаем ключ за текущим компьютером:

Ssh-keygen -t rsa

Ключ создан, теперь его необходимо добавить на удаленную машину или сервер.

Как добавить SSH-ключ на сервер?

Для этого вводим команду:

ssh-copy-id ИмяПользователя @IPадрес

Ssh-copy-id sasha@ 100.08.30.48

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

Клиент SSH Windows

Одной из самых популярных программ для работы c Linux серверами по SSH в Windows является программа Putty. Скачать данный SSH клиент Windows можно по данному адресу — putty.org .

Подключение по SSH по паролю в Windows

Подключение в Putty по SSH очень простое! Вводим IP адрес, если меняли порт, то указываем другой порт и нажимаем Open:
и после подключения логин и пароль!

Подключение по SSH по ключу в Windows

Если вам не хочется вводить каждый раз пароль, а использовать ключ ssh в Putty, то, как и в Linux, сначала необходимо создать ключ, а после перенести его на сервер.

Создаем ключ

Программу пока не закрываем и запускаем Putty для подключения

Перенос ключа

Mac SSH Client

Так как macOS основана на UNIX системе, то подключатся по ssh можно прямо из терминала!

Если есть желание не использовать пароль, то необходимо вначале установить Homebrew:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Есть также удобный mac ssh client — Termius .

SSH клиент android и iOS

Наиболее удобным клиентом SSH для iOS и Android является приложение Termius!

Передача и скачивание файлов по SSH (SCP)

Для того чтобы закачать файл с локальной машины на сервер по ssh в Linux и macOS:

Scp file1.tar root@ip_adress:/home/dir

Копирование файла с сервера на локальный компьютер Linux или macOS:

Scp userName@ip_adress:/home/file1.tar /var/www/

C сервера, на сервер:

Scp user@server_ip1:/home/file.txt user@server_ip2:/home/

Для Windows

Для перемещения файлов по SSH в Windows используется pscp .

pscp.exe file.zip root@ip_server: /var/www/

Настройка SSH

Если необходимо добавить вход в SSH сразу по root:

Смена порта SSH

Так как по умолчанию работа ssh настроена на порту 22, то пользоваться сервером становится не безопасно. Поэтому стоит сменить порт!

и поменяйте значения Port на необходимые:

# What ports, IPs and protocols we listen for Port 22

Вход только по ключу SSH:

С помощью nano отредактируйте документ sshd_config, введите команду:

Sudo nano /etc/ssh/sshd_config

Поменяйте значения PasswordAuthentication с yes на no:

RSAAuthentication yes PubkeyAuthentication yes PasswordAuthentication no

У вас еще остались вопросы? Пишите их в комментариях, рассказывайте, что у вас получилось или наоборот!

Вот и все! Больше полезных статей и инструкций читайте в разделе . Оставайтесь вместе с сайтом , дальше будет еще интересней!

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

Служба ssh позволяет получить доступ к терминалу удаленного компьютера и выполнить там все необходимые вам команды. При своей простоте она достаточно безопасна, чтобы использоваться для решения серьезных коммерческих задач, так и задач обычных пользователей. В этой статье мы рассмотрим как выполняется установка ssh Ubuntu 16.04, а также поговорим о начальной настройке ssh сервера.

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

За поддержку протокола SSH в Linux отвечает набор программного обеспечения OpenSSH. Это открытая реализация этого протокола, которая предоставляет все необходимые возможности. В состав пакета OpenSSH входят утилиты для установки соединения, передачи файлов, а также сам ssh сервер.

Установка OpenSSH в Ubuntu

Установить ssh на Ubuntu будет очень просто, программа считается стандартной и используется почти везде. Хотя по умолчанию в дистрибутиве ее нет, но зато она есть в официальных репозиториях.

Поэтому для установки откройте терминал с помощью сочетания клавиш Ctrl+Alt+T и выполните команду:

sudo apt install openssh-server

Будет загружено несколько пакетов, а когда установка ssh сервера Ubuntu завершится, программа будет готова к работе. Если вы хотите чтобы служба запускалась автоматически нужно добавить его в автозагрузку. Поэтому чтобы включить ssh Ubuntu 16.04 выполните:

sudo systemctl enable sshd

Если затем вы захотите удалить службу из автозагрузки, используйте команду disable:

sudo systemctl disable sshd

Что касается клиента ssh, то он уже установлен в системе по умолчанию. Сейчас вы можете попробовать подключиться к локальному ssh серверу просто набрав:

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

Точно таким способом вы можете получить ssh доступ ubuntu к любому другому компьютеру из сети. Для этого достаточно указать вместо localhost его ip адрес и имя пользователя в таком формате:

$ ssh имя_пользователя @ ip_адрес

Настройка SSH в Ubuntu

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

Перед тем как вносить изменения в этот конфигурационный файл рекомендуется сделать его резервную копию, для этого можете использовать такую команду:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.factory-defaults

sudo vi /etc/ssh/sshd_config

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

По умолчанию вход от имени суперпользователя включен, рекомендуется отключить такую возможность. Для этого найдите строчку PermitRootLogin и замените ее значение на no:

Чтобы разрешить аутентификацию по ключу, а не по паролю найдите строку PubkeyAuthentication и убедитесь, что ее значение yes .

После того как все настройки будут завершены, сохраните изменения нажав:w и перезапустите службу ssd:

sudo systemctl restart ssh

Более подробно про настройку и использование различных тонкостей ssh рассказано в статье .

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

ssh -p 2222 localhost

К тому же, если на компьютере установлен и настроен брандмауэр, то в нем тоже нужно разрешить доступ к новому порту ssh, для этого выполните:

sudo ufw allow 2222

Даже если служба ssh находится на порту по умолчанию, его тоже нужно открыть в брандмауэре если вы собираетесь подключаться к компьютеру через интернет:

sudo ufw allow 22

Настройка ssh Ubuntu 16.04 полностью завершена.

Выводы

Теперь, когда установка ssh Ubuntu 16.04 завершена, вы можете получить удаленный доступ к своему компьютеру через интернет и быть уверенными что он находится в безопасности. Если у вас остались вопросы, спрашивайте в комментариях.

На завершение видео, где подробно рассказано о том, что такое ssh:

Здравствуйте! Интересует вопрос: как подключиться по SSH к домашнему компьютеру через интернет. Дома установлен FreeSSHd сервер. Я так понимаю надо как-то открыть порт 22 на внешнем IP?Alex

Да, часто возникает необходимость . Я в той статье много о чём рассказывал, а здесь мы будем говорить исключительно об SSH, раз уж Alex любезно предоставил нам эту возможность. К тому же, мне самому безумно интересен SSH, а здесь ещё и на Windows… ммм.

Что такое SSH и зачем он нужен?

Дело в том, что SSH — это S ecure SH ell. Протокол для безопасного доступа к оболочке управления. Поэтому оно предоставляет доступ именно к командной строке, ибо Shell — переводится как оболочка и здесь в значении текстовая оболочка управления . Но вообще, этот протокол примечателен тем, что он позволяет пропускать внутри себя любой другой трафик, причем в зашифрованном виде. Так, протокол безопасного подключения к файловой системе называется SFTP и работает поверх SSH. Но может туннелировать абсолютно любые другие соединения — будь то HTTP или даже RDP. По сути получается «VPN на коленке».

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

По крайней мере штатный — cmd — мало что позволяет сделать с удалённой машиной. Есть ещё Powershell — это уже более современное и мощное решение. Freesshd позволяет сменить консоль на powershell, но я к ней так и не смог подключиться. К CMD подключился — но это совершенно неюзабельно:

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

Поэтому, я предполагаю, что Алексу понадобился ssh-сервер на Windows для подключения к файловой системе или использования её в качестве VPN, проксирования чего-либо поверх SSH. Хотя я и сомневаюсь, что FreeSSHd позволит это делать. Ибо в-третьих: он даже не сохраняет настройки, при перезапуске сервиса всё сбивается. В общем, я очень надеюсь, что Алекс расскажет нам в комментариях о том, зачем это ему понадобилось.

Как ещё можно запустить SSH на Windows?

Есть более работоспособное решение — Powershelserver . Хотя в нём тоже есть баги, но оно хотя бы не вылетает. Поэтому я бы рекомендовал использовать именно его для подключения по SSH к виндовым серверам.

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

Все настройки нормально сохраняются. Доступны те же функции что и в FreeSSHd и даже больше — можно использовать SCP — это копирование файлов поверх SSH.

Но самый шик — это консоль! Она работает, господа!

Я легко подключился, без всяких плясок с добавлением пользователей (это нужно делать во freesshd). И та простейшая команда на просмотр таблицы маршрутизации прекрасно отработала и выдала нужную инфу. Фриссш у меня «упал» именно при попытке просмотра netstat -rn

Здесь правда видно что не отображаются русские символы. Так у нас это легко настроить, просто выставляю нужную мне кодировку на powershellserver, перезапускаю, переподключаюсь…

Настройка кодировки в Powershellserver

Теперь мы имеем полноценный SSH и можем полностью управлять Windows через консоль.

Microsoft создаст собственное решение для SSH

Кстати, Microsoft eщё летом объявила о том, что собирается разработать нативную поддержку SSH для Powershell в новых версиях Windows. Есть анонсы новости на хабре и на pcweek (и ещё). Поэтому нам только остаётся ждать с нетерпением этого знакового события, поскольку это действительно будет прорывом для работы в гетерогенных сетях .

Я не стал проверять остальные функции — sftp и scp, но почему-то уверен, что они тоже будут прекрасно работать.

Как открыть снаружи SSH-порт?

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

Проброс порта на роутере или модеме

Для подключения к компьютеру извне, действительно нужно сделать NAT, или, в частном случае . Как это сделать зависит от устройства, которое используется в качестве шлюза. Это может быть ADSL-модем или . В большинстве случаев подробные инструкции для вашего девайса легко найти по запросам типа «проброс порта модель_устройства » или «port forwarding модель_устройства »

Вот так это выглядит на моем домашнем роутере Zyxel Keenetic Lite:

А вот так это выглядит на ADSL-модеме c функционалом роутера Linksys WAG200G, оказавшимся под рукой:

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

Проброс порта на удалённый сервер с помощью SSH-туннеля

В таком случае, для подключения по SSH может быть доступен единственный способ — с локальной Windows-машины (той самой, к которой хотим подключиться по SSH) на удалённый сервер. В этом случае у вас должен быть SSH-доступ к какому-то серверу в интернете.

Настройка «обратного» туннеля SSH

Такой проброс легко сделать с помощью простого SSH-клиента Putty (есть и ) Затем можно будет подключиться на этом самом удалённом сервере через проброшенный порт.

Здесь получилась по сути петля. Мы открываем SSH сессию с Windows на удалённый сервер, а внутри этого подключения у нас туннелируется SSH-порт самой Windows Powershellserver (или FreeSSHd) на локальный порт 3322 удалённого сервера. И в этой же сессии мы теперь подключаемся обратно к Windows на Powershell через этот самый порт 3322… Я надеюсь, вы не запутались. Но… This is magic, друзья! :) SSH-туннели это особый мир, с их помощью можно вытворять невероятные штуки, открывать такие двери, что все безопасники будут горько плакать, если бы они вдруг узнали обо всём этом… Ну да ладно .

Ну если вам нужно расшарить SSH-порт винды в мир, достаточно в настройках обратного туннеля в качестве destination указать не localhost:3322, а ip_server:3322. Сможете подключаться к винде по SSH отовсюду, где есть доступ к этому самому серверу.

Как проверить правильно ли проброшен порт?

Очень просто. Нужно проверить открыт ли он. В случае с SSH открытый порт будет отвечать сообщением о своей версии. Самый простейший способ проверки порта — утилита telnet.

Просто наберите в командной строке через пробел:

telnet домен_или_IP порт

Если порт доступен, то вы увидите что-то вроде такого:

Ответ SSH если порт доступен

Если порт по каким-то причинам недоступен — то вы увидите либо «connection refused» либо «connection timeout». В первом случае это будет мгновенно, и означает что порт закрыт файрволом.

Во втором случае это будет похоже на «зависание» и может длиться до нескольких минут — телнет-клиент будет пытаться установить соединение. Это может означать также блокировку файрволлом, но уже другого типа. Либо просто что указанный хост недоступен или порт на нём закрыт.

Если вы смогли подключиться телнетом, то нажмите комбинацию клавиш Ctrl+] и введите quit, затем Enter. Иначе не получится прервать сессию и придётся открывать новое окно консоли, если она вам ещё нужна.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в.ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов - прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете )

Управление ключами

Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая - в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок - пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер - ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа

Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

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

Сменить пароль на ключ можно с помощью команды ssh-keygen -p .

Структура ключа

(если на вопрос про расположение ответили по-умолчанию).
~/.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 вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да - ключ сохраняется в файл ~/.ssh/known_hosts . Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), 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.

Копирование файлов

Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp , которая осуществляет копирование файла через ssh-сессию.

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).

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

Так тоже можно:

sshfs

Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: 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 может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

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

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

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).

Опции по умолчанию

По подсказке UUSER : вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host * User root Compression yes

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd _config), но это требует прав рута и распространяется на всех пользователей.

Проброс X-сервера

Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 - это как раз оно.

Теория: Графические приложения в юникс обычно используют 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-трафика.

Socks-proxy

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

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то 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)

Проброс портов

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (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» не отличим от обычного трафика компьютера А.

Туннелирование

Если к этому моменту попа отдела безопасности не сияет лысиной, а 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-ключ, который бы авторизовывал [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-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет - взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage .

Настройка завязана на две возможности 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 Добавить метки