Ssh порт 22: Нужно ли менять Port 22, зачем и как это делать

Нужно ли менять Port 22, зачем и как это делать

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

Какие настройки SSH по умолчанию стоит заменить

К сожалению, интернет-среда буквально пропитана мифами и легендами. После появления очередной “утки” все программисты реагируют, а со временем люди уже забывают, что это всего лишь миф и продолжают делать все по предписанным правилами, которые, возможно, и не правила вовсе. И как же разобраться в этой пучине надуманных законов и ложных советов? Лучший помощник в этом вопросе – это практика и мудрость опытных программистов.

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

К примеру, вам стоит сразу же отредактировать данные по root-пользователю. Никак нельзя его подпускать к серверу SSH – это чревато необратимыми последствиями. Мало того, что хакер может проникнуть к вам на компьютер через аккаунт суперадминистратора, так и вы сами способны нанести вред серверу SSH, ведь у root неограниченные права. Никак нельзя допускать кому-либо выполнять команды sudo удаленно, а по умолчанию суперадмину дозволено входить на сервер SSH. Так что начните с того, что запретите ему доступ.

Другая ненадуманная настройка, которая стоит по умолчанию, и ее нужно отредактировать, – это способ аутентификации. Никак нельзя оставлять старый метод авторизации путем стандартного ввода пароля. Вы для того и используете протокол SSH, чтобы обезопасить себя от прецедентов взлома паролей. В SSH есть и более умные способы аутентификации. Возьмите тот же открытый ключ – такую систему авторизации практически невозможно взломать, так как вы ничего при входе на сервер вводить не будете – аутентификация пройдет посредством сверки публичного ключа на компьютере. Единственный способ взломать такую защиту – это напрямую вломиться в квартиру пользователя, и завладеть его компьютером с публичным ключом.

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

Но стоит ли менять порты? Точнее стоит ли менять стандартный порт, который прописан в SSH по умолчанию? Как известно, это значение равно – Port 22. И по поводу этой строки у многих программистов возникает масса вопросов. Одни уверенно твердят, что нельзя поддавать себя такой опасности и лучше просто заменить порт. Другие говорят, что и Port 22 – это нормально и ничего страшного произойти не может, если игнорировать стандартный порт в настройках.

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

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

Еще одна неприятность, которая подстерегает тех, кто решился заменить port 22 на другое значение – это возможные сбои в работе. Все-таки, не зря разработчики протокола SSH выбрали именно Port 22 для стандартных настроек. Видимо, этот порт лучше других подходит для обеспечения взаимодействия сервера и клиента, и если заменить port 22 на другой, можно поплатиться потерей функциональности, вплоть до потери возможности работать с сервером. Но если вы все же не боитесь приведенных предостережений, то разберем следующие вопросы: как изменить port 22 и как создать forwarding (переадресацию) портов.

Как изменить стандартный порт

Итак, теперь переходим от дискуссии к непосредственной практике – нужно изменить стандартный порт на другой. Сразу возникает вопрос: а на какой порт менять 22-й? Неужели нет разницы в этой цифре? На самом деле разница есть, потому и нужно быть предельно аккуратным при замене номера порта. Хотя многие советуют ставить рандомное значение для этого параметра, лишь бы оно не превышало верхний предел 65535 – выше уже нет портов. То есть вы можете поставить к себе в настройках порт 12345 и любой другой, и от этого якобы ничего не случится. Но на деле все гораздо сложнее.

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

Теперь, когда вы осознали всю ответственность, которую берете на себя, решив изменить стандартное значение порта, можете приступить к его замене. Номер порта указан в файле конфигураций – /etc/ssh/sshd_config. Чтобы его заменить, воспользуйтесь терминалом для вызова этого файла – введите следующую строку: nano /etc/ssh/sshd_config. После открытия файла через поиск или вручную найдите строку Port 22 и поменяйте цифру 22 на другое значение, которое по вашим наблюдениям является свободным. Многие рекомендуют не менять строку Port 22, а закомментировать ее и снизу прописать другой Port с новым значением. Сделать это несложно, так что вы тоже можете так поступить.

Если у вас не получается самостоятельно проверить, какие порты в данный момент заняты различными службами, тогда можете воспользоваться специальной командой. Зайдите в терминал и введите следующую строку: netstat -tupln | grep LISTEN. Перед вами появится список задействованных портов и вам останется лишь придумать свое значение, которого нет в приведенном перечне. После того, как закомментируете текущее значение порта и добавите строку с новым, не забудьте сохранить изменения и перезапустить сервер. Без перезагрузки нововведения не вступят в силу. Для перезапуска введите в терминал команду /etc/init.d/ssh restart, либо если у вас sshd, то пропишите /etc/init.d/sshd restart.

Как сделать forwarding и перенаправить порты

Функция forwarding необходима для двух целей: во-первых, чтобы организовать переброс различных ip-адресов и портов и создания туннелей, а во-вторых, агент forwarding позволяет клиенту переходить между серверами. Начнем со второго предназначения агента forwarding – он нужен, если у вас не один сервер и вы не хотите каждый раз проходить авторизацию заново, а желаете используя один и тот же публичный ключ перемещаться с сервера 1 на сервер 2. Чтобы настроить такой forwarding, вам необходимо изменить настройки файла конфигураций – прописать следующую строку в нем: ForwardAgent yes.

Теперь разберемся с туннелями между хостами и тем, как при помощи forwarding настроить переброс с одного ip-хоста с определенным портом на другой. А сделать это весьма просто. К примеру, если вы хотите настроить 2220 порт для переброса ip-адреса 97.86.77.66 на 10.12.11.13 мы вводим следующую строку: ssh -f -N -R 2222:10.12.11.13:22 [email protected]. Где буква -f это и есть функция forwarding. Теперь, когда пользователь введет запрос для получения доступа к локальному хосту 97.86.77.66, сработает переброс (forwarding) и он будет перемещен на 2222-й порт 10.12.11.13. Аналогично этому принципу можно настроить forwarding для перебрасывания любого ресурса куда угодно, к примеру, для перенаправления в Сеть.

Что касается целей создания туннелей, они могут быть самыми разнообразными. Поскольку SSH использует шифрование данных, то туннелирование может понадобится для передачи различных зашифрованных файлов, например, IMAP IRC или VNC. Туннелирование позволит вам принимать на сервер различные типы трафика. Кроме того, часто перенаправление портов и IP-адресов используют для обхода плохо настроенных маршрутиризаторов, сетевых анализаторов трафика и прочих ограничителей. Но учитывайте, что после добавления переадресации, возможно, понадобится изменить настройки некоторых программ, через которые вы осуществляете соединение по SSH каналам.

Как изменить порт SSH в Linux

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

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

В этой статье объясняется, как изменить стандартный порт SSH в Linux. Мы также покажем вам, как настроить брандмауэр, чтобы разрешить доступ к новому порту SSH.

Изменение порта SSH

Выполните следующие действия, чтобы изменить порт SSH в вашей системе Linux:

1. Выбор нового номера порта

В Linux номера портов ниже 1024 зарезервированы для известных служб и могут быть связаны только с правами root. Хотя вы можете использовать порт в диапазоне 1-1024 для службы SSH, чтобы избежать проблем с распределением портов в будущем, рекомендуется выбирать порт выше 1024.

В этом примере порт SSH изменится на 3452, вы можете выбрать любой порт, который вам нравится.

2. Настройка брандмауэра

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

Если вы используете UFW, средство настройки брандмауэра по умолчанию для Ubuntu запускает следующую команду, чтобы открыть новый порт SSH:

sudo ufw allow 3452/tcp

В CentOS инструментом управления брандмауэром по умолчанию является FirewallD. Чтобы открыть новый порт, выполните следующие команды:

sudo firewall-cmd --permanent --zone=public --add-port=3452/tcp
sudo firewall-cmd --reload

Пользователям CentOS также необходимо настроить правила SELinux, чтобы разрешить новый порт SSH:

sudo semanage port -a -t ssh_port_t -p tcp 3452

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

sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

3. Редактирование конфигурации SSH

Откройте файл конфигурации SSH /etc/ssh/sshd_config в текстовом редакторе:

sudo nano /etc/ssh/sshd_config

Поиск строки, начинающейся с Port 22. В большинстве случаев эта строка начинается с хеша #. Удалите хэш #и введите новый номер порта SSH, который будет использоваться вместо стандартного порта 22 SSH.

/etc/ssh/sshd_config

Port 3452

Будьте особенно осторожны при изменении файла конфигурации SSH. Неправильная конфигурация может привести к сбою службы SSH.

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

sudo systemctl restart ssh

В CentOS сервис ssh называется sshd:

sudo systemctl restart sshd

Чтобы убедиться, что демон SSH прослушивает новый порт 3452, введите:

ss -an | grep 3452

Вывод должен выглядеть примерно так:

tcp   LISTEN      0        128            0.0.0.0:3452           0.0.0.0:*
tcp   ESTAB       0        0      192.168.121.108:3452     192.168.121.1:57638
tcp   LISTEN      0        128               [::]:3452              [::]:*

Использование нового порта SSH

Теперь, когда вы изменили порт SSH при входе на удаленный компьютер, вам нужно будет указать новый порт.

Используйте опцию  -p <port_number> чтобы указать порт:

ssh -p 3452 username@remote_host_or_ip

Заключение

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

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

Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Как изменить порт SSH 22 у сервера Linux

? ?????? ????? ?? ?????????? ??????????? ????? ???????????? ????? 22. ????????? ????? ??? ??????? ????????? ? ??? ???????, ????? ??? ?????? ???????????? ???? ?????? (??????? ?????? ??? ????????? ??????? ? ???????), ??? ????? ????? ?? ?????????? ?????? ? ????? ???????????? (?? ????, ?? ???????), ?? ?? ???? ?????????? ???????? ??? ?????????, ????? ??????? ?? ?????????? ?????? ?????? ???????.

????? ????? ?? ???????? ??????? ???????, ?? ????? ???? ??????. ? ?????? ?????? ??????? ? ??????? ?? SSH, ? ??? ?????? ???? ?????? ? VNC. ??. ?????? ??????????? ? VNC ??????? ? ?????????????? ????????? UltraVNC (????????? ???????).

?????????????? ???????? ?????????? ??? ????, ????????, 3195. ?????????? ???????? ?? ?? ????????:

netstat -tupln | grep LISTEN

??? ?????????????? ?????? ????? ? ????????, ?????????????? ??????? ??????? ???????? ?? ??????????? ????:

iptables -I INPUT -p tcp —dport 3195 -m state —state NEW -j ACCEPT

????????? ????????? ????????:

service iptables save

????? ???? ??? ???? ?????? ? ????????, ????????? ? ??????? ?????? ?????. ????????? ???????????????? ???? ????????:

vi /etc/ssh/sshd_config

???? ??????? ????????? ?????. ???? ????? ???? ?? ???????, ?? ????? ???????????????:

#Port 22

? ?????? ?? ??????????? ????????, ? ????? ??????? ??? 3195 (?? ????? ????? ??????????????? «#»:

Port 3195

????????? ????????? ????????????????? ?????.

??? ?????????? ???? ????????? ????????? ???????????? SSHD:

systemctl restart sshd.service

????? ?????????? ???? ???????? ??????????? ? ??????? ????????????? ? ????????? ?????? ?????.

? ?????? ???? ??? ????????? ?????? ? ????????? ???????????? ????? SSH 22, ?? ?? ?????-???? ???????? ????????? ?????? ?? ?????????????? ?????????, ?? ?????? ?????????? ? ????? ????????? ???????? ? ?????? ????? ???????? ?????????????????, ?????????? ? ???????? ????? ONLY SSD.

Как изменить стандартный порт SSH в Linux (правильно и безопасно)

Если вы знакомы с основами SSH, вы уже знаете, что SSH использует порт 22 по умолчанию.

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

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

• Откройте файл /etc/ssh/sshd_config для редактирования.
• Найдите строку, которая имеет Port 22 (если она закомментирована с #, удалите также и #).
• Измените линию на порт 1132 (или любой номер по вашему выбору между 1024 и 65535).
• Убедитесь, что новый порт разрешен брандмауэрами (если есть).
• Перезапустите ssh-демон с помощью sudo systemctl restart sshd.
• Отныне вам нужно будет указать порт для подключения по ssh ssh user@ip_address_of_server -p 1132.

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

Зачем менять порт SSH по умолчанию?

Одним из самых простых приемов защиты SSH-сервера является изменение стандартного номера порта SSH 22.

Зачем? Поскольку ряд скриптов-ботов пытаются использовать атаки грубой силы на порте 22 по умолчанию. Большинство из этих скриптов не всегда сканируют открытые порты и нацелены на порты по умолчанию для различных известных служб, таких как SSH.

Изменение порта SSH по умолчанию уменьшает количество таких атак. Есть и другие способы повысить безопасность вашего SSH-сервера. Если вам интересно, следуйте этим практическим советам по улучшению безопасности SSH-сервера.

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

Разрешить трафик на новый порт, изменив настройки брандмауэра

Если у вас установлен брандмауэр или пользовательский ipconfig или ifconfig или вы используете selinux, вы должны разрешить новый порт ssh перед внесением изменений. В противном случае вы можете заблокировать себя без доступа SSH.

Теперь эта часть зависит от того, какой тип брандмауэра или маршрутизации вы используете.

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

sudo ufw allow 1132/tcp

Если вы используете iptables, вы должны использовать эту команду:

sudo iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 1132 -j ACCEPT

В Fedora, CentOS , Red Hat брандмауэр управляется firewalld, и вы можете использовать эту команду:

sudo firewall-cmd --permanent --zone=public --add-port=1132/tcp
sudo firewall-cmd --reload

В CentOS и Red Hat вам также может потребоваться изменить правила SELinux:

sudo semanage port -a -t ssh_port_t -p tcp 1132

Теперь, когда вы установили правильные настройки брандмауэра, давайте перейдем к изменению порта SSH.

Изменение порта SSH по умолчанию

Обычно файл конфигурации ssh находится по адресу /etc/ssh/sshd_config. Для редактирования файла вам понадобится редактор на основе терминала, такой как Vim, Nano или Emacs.

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

sudo nano /etc/ssh/sshd_config

Как видите, для редактирования конфигурации ssh вы должны быть пользователем sudo или пользователем root.

Прокрутите немного вниз, и вы увидите строку с Port 22. Если это начинается с #, это означает, что строка закомментирована. Закомментированные строки дают вам настройки по умолчанию.

Так что, если вы видите # Port 22, это означает, что порт по умолчанию – 22.

Измените эту строку с номером порта по вашему выбору. В Linux номер порта 0-1023 обычно зарезервирован для различных служб. Хорошо избегать использования значений от 0 до 1023, чтобы избежать конфликтов.

Вы можете использовать любой другой номер порта от 1024 до 65535. Мы используем 1132 в примере. Убедитесь, что вы удалили символ # перед портом.

Сохраните изменения и выйдите из редактора. Если вы используете Nano, используйте Ctrl + X для сохранения и выхода.

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

sudo systemctl restart sshd

Теперь, если вы хотите получить доступ к SSH-серверу, вам нужно будет указать номер порта:

ssh user@ip_address_of_server -p 1132

Было ли это полезно?

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

удобная работа с файлами по SSH / Блог компании RUVDS.com / Хабр

Если у вас имеется больше одного Linux-компьютера, то вы, вероятно, постоянно пользуетесь ssh. Это — отличный инструмент, но мне всегда казалась в нём странной одна деталь. Несмотря на то, что ssh-соединения позволяют передавать файлы с применением scp и sftp, у нас нет возможности перемещать файлы между локальной и удалённой системой, не запуская программу на локальном хосте, или не подключаясь к локальной машине с удалённой.

Последнее — это настоящая проблема, так как к серверам часто подключаются, находясь в это время за файрволом или за NAT-маршрутизатором, то есть, не имея постоянного IP-адреса. В результате сервер, в любом случае, не сможет подключиться к локальной системе, с которой раньше к нему обращались. Если бы в ssh-сессии можно было бы просто взять локальный или удалённый файл и передать его туда, куда нужно, это было бы очень удобно.

Я, на самом деле, не вполне достиг этой цели, но подобрался к её достижению очень близко. В этом материале я расскажу вам о скрипте, который позволяет монтировать удалённые директории на локальном компьютере. На локальной машине надо будет установить sshfs, но на удалённой, на которую вы, возможно, не можете устанавливать программы, ничего менять не придётся. Если же потратить на настройку систем некоторое время, и если на клиентском компьютере имеется работающий ssh-сервер, то можно будет ещё и монтировать локальные директории на удалённых системах. При этом не придётся беспокоиться о блокировке IP-адресов или портов. Фактически, если вы способны подключиться к удалённой машине, это означает, что вам удастся и то, о чём я хочу рассказать.

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

Нет ли тут подвоха?

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

Кроме того, работу значительно облегчает скрипт, о котором я расскажу. Он скрывает от пользователя детали, поэтому процедура подключения выглядит (почти) как обычно, а после этого всё работает как надо.

Пара слов о sshfs

Утилита sshfs даёт возможность работать с файловой системой в пользовательском пространстве (filesystem in userspace, FUSE). То есть, речь идёт о том, что в пользовательском пространстве имеется слой, находящийся поверх базовой файловой системы. В данном случае такой файловой системой является ssh-сервер, поддерживающий sftp. Это позволяет работать с файлами, находящимися на удалённой системе, воспринимая их так, будто они находятся в реальной файловой системе на локальном компьютере. Если вы ещё не пробовали sshfs — попробуйте. Работает эта утилита очень хорошо.

Предположим, вы вошли на компьютер myserver и выполнили с локальной машины следующую команду: 

sshfs myserver:/home/admin ~/mounts/myserver

Это приведёт к тому, что директория удалённого компьютера /home/admin будет доступна в локальной системе по пути ~/mounts/myserver.

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

Так как sshfs использует удалённо смонтированную версию файла, то все изменения, внесённые в файл, сохраняются на удалённой машине. А после того, как sshfs-соединение закрывают, на локальной компьютере ничего не остаётся. Сейчас мы это исправим.

Предварительная подготовка

Прежде чем я перейду к описанию скрипта, о котором было упомянуто выше, хочу рассказать о некоторых настройках клиента, которые вы, если хотите, можете доработать под себя. Так, тут я создаю директорию ~/remote, а в ней создаю поддиректории для каждого удалённого компьютера. Например — это могут быть директории ~/remote/fileserver и ~/remote/lab.

Скрипт называется sshmount. Он принимает те же аргументы, что и ssh. Для упрощения работы со скриптом сведения об удалённом хосте стоит хранить в файле ~/.ssh/config, что позволит пользоваться простыми и короткими именами хостов. Например, сведения о компьютере lab могут выглядеть так:

Host lab
Hostname lab.wd5gnr-dyn.net
Port 444
User alw
ForwardX11 yes
ForwardX11Trusted yes
TCPKeepAlive yes
Compression yes
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

На самом деле, острой необходимости в этом нет, но при таком подходе в вашем распоряжении будет приятно выглядящая директория ~/remote/lab, а не сложная конструкция вида ~/remote/[email protected]:444. Во всех этих параметрах нет ничего таинственного. Единственно, хочу обратить ваше внимание на то, что ControlMaster и ControlPath позволяют организовать более быструю работу с соединениями, что, в нашем случае, очень важно.

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

Скрипт

Наш скрипт можно использовать двумя способами. Так, если его вызывают через ссылку к sshunmount, то он размонтирует файловую систему, связанную с указанным удалённым хостом. Если его вызывают иначе (обычно — как sshmount), то он выполняет следующие три действия:

1. Он проверяет, есть ли в директории ~/remote поддиректория, имя которой совпадает с именем хоста (например — lab). Если такой директории нет — он выводит сообщение об ошибке и продолжает работу.
2. Если такая директория существует — скрипт просматривает список смонтированных файловых систем на тот случай, если нужная файловая система уже смонтирована. Если это так — он продолжает работу.
3. Если директория не смонтирована — он вызывает sshfs и продолжает работу.

Этот скрипт можно найти на GitHub. А вот его код, из которого убраны некоторые комментарии:

#!/bin/bash
 
if [ "$1" == "" ]
then
echo Usage: sshmount host [ssh_options] - Mount remote home folder on ~/remote/host and log in
echo or: sshunmount host - Remove mount from ~/remote/host
exit 1
fi
 
# Если вызван как sshunmount...
if [ $(basename "$0") == sshunmount ]
then
echo Unmounting... 1>&2
fusermount -u "$HOME/remote/$1"
exit $?
fi
 
# Обычный вызов...
if [ -d "$HOME/remote/$1" ] # Существует ли директория?
then
if mount | grep "$HOME/remote/$1 " # Файловая система уже смонтирована?
then
echo Already mounted 1>&2
else
sshfs -o reconnect $1: $HOME/remote/$1 # mount
fi
else
echo No remote directory ~/remote/$1 exists 1>&2
fi
ssh $@ # выполнить вход

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

Решаем обратную задачу

Если вы хотите поэкспериментировать с монтированием на сервере папок, находящихся на локальной машине, то нужно будет, чтобы на локальной машине работал бы ssh-сервер. Конечно, если ваш локальный компьютер видим и доступен серверу, то это просто: достаточно запустить на удалённом компьютере sshfs и смонтировать на нём папку с локального компьютера. Но во многих случаях у нас нет доступа к локальной системе, которая может быть расположена за файрволами или маршрутизаторами. Особенно это актуально в том случае, если роль локальной системы выполняет ноутбук, который может подключаться к сети из разных мест.

Но нашу задачу, несмотря на все эти сложности, всё же, можно решить. Её решение состоит из двух частей.

Во-первых — надо, при вызове sshmount, указать дополнительный аргумент (файл можно отредактировать в том случае, если вам нужно будет постоянно выполнять подобную команду):

sshmount MyServer -R 5555:localhost:22

Во-вторых — после подключения к хосту нужно выполнить такую команду:

sshfs -p 5555 localhost:/home/me ~/local

Благодаря опции -R на удалённой машине создаётся сокет на порте 5555 (который, естественно, должен быть свободным) и осуществляется его связь с портом 22 локальной машины. Если исходить из предположения о том, что ssh-сервер работает на порте 22, то это позволит серверу подключиться к локальной машине по тому же соединению. Ему не нужно знать наш IP-адрес или иметь открытый порт.

Команда sshfs, которую можно выполнять при запуске системы, связывает локальную директорию /home/me с директорией ~/local удалённого сервера. Если, вдобавок, войти в систему локально, то можно будет взглянуть на переменные окружения, имена которых начинаются с SSH_, и узнать подробности о SSH-соединении. Например, это переменные $SSH_CLIENT и $SSH_TTY.

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

Итоги

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

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

Чем вы пользуетесь для работы с файлами удалённых Linux-систем?

Устранение неполадок подключения по SSH в Linux

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

Неправильное имя хоста

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

$ ssh [email protected]
ssh: Could not resolve hostname hostname.com: Name or service not known

Это значит, что имя хоста «hostname.com» не может быть сопоставлено с IP-адресом сервера SSH. Зачастую, это связано с работой DNS. В первую очередь, следует убедиться в правильности написания самого имени хоста. Также можно проверить разрешение этого хоста с помощью команды ping или сторонних сервисов. Если же во всех случаях наблюдается та же ошибка, можно попытаться подключиться, используя непосредственно IP-адрес:

$ ssh [email protected]

Ошибка с истечением времени соединения

Такая ошибка происходит, когда сервер SSH не может ответить подключающемуся к нему клиенту в течение определённого промежутка времени:

$ ssh [email protected]
ssh: connect to host 123.123.123.123 port 22:
Connection timed out

Для исправления этой ошибки необходимо в первую очередь сделать следующее:

• проверить правильность имени и/или IP-адреса хоста сервера SSH;
• проверить, что указанный порт (22) доступен для подключения. В некоторых сетях он может быть заблокирован;
• проверить режим политики брандмауэра, политика которого по-умолчанию должна быть не DROP.

Отклонение соединения

Данная ошибка схожа с ошибкой истечения времени соединения и выглядит следующим образом:

$ ssh [email protected]
ssh: connect to host 123.123.123.123 port 22:
Connection refused

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

Настройка брандмауэра

Как известно, брандмауэры могут блокировать определённые порты и/или сетевые сервисы. Брандмауэров существует множество и в разных дистрибутивах Linux используются разные брандмауэры. Так, для Ubuntu это UFW, а для CentOS – FirewallD. Также можно использовать стандартный сервис iptables.

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

$ iptables -nL
Chain INPUT (policy ACCEPT)
target    prot   opt   source                           destination
Chain FARWARD (policy ACCEPT)
target    prot   opt   source                           destination
Chain OUTPUT (policy ACCEPT)
target    prot   opt   source                           destination

Если политика iptables по-умолчанию DROP (или REJECT), то необходимо для правил цепочки INPUT задать разрешение для порта, используемого для SSH.
Для брандмауэра FirewallD получить список используемых правил позволяет команда:

$ firewall-cmd --list-services

Для работы SSH в выводе должно быть правило «dhcpv6-client http ssh». Также необходимо проверить и порт, заданный для SSH. Для этого вместо опции «—list-services» нужно использовать «—list-ports».
Для брандмауэра UFW нужно выполнить:

$ ufw status
Status: active
To Action From
-- ------- ------
22 LIMIT Anywhere
443 ALLOW Anywhere
. . .
22 (v6) LIMIT Anywhere (v6)

Как видно, в списке должен присутствовать порт SSH, в данном случае 22. Он может быть и другим, в зависимости от того, что задано в настройках сервера SSH.

Проверка состояния сервера SSH

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

$ systemctl status sshd
sshd.service – OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
Active: active (running) since Fri 2019-04-05 11:00:46 EDT; 1 mounth 1 days ago
Process: 899 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCES)
Main PID: 906 (sshd)
Cgroup: /system.slice/sshd.service
├─ 906 /usr/sbin/sshd -D
├─26941 sshd: [accepted]
└─26942 sshd: [net]

В случае, если демон SSH не работает, то в строке Active будет следующее:

Active: inactive (dead) since Fri 2019-04-05 08:36:13 EDT; 2s ago

Для запуска демона следует использовать команду:

$ systemctl start sshd

Следует также обратить внимание на то, что обычно в дистрибутивах CentOS демон SSH называется sshd, а в Ubuntu – ssh.

Проверка порта для работы SSH

Чтобы проверить, какой порт настроен для использования сервером SSH, можно просмотреть соответствующий параметр в конфигурационном файле /etc/ssh/ssh_config. Для этого можно использовать команду grep для поиска по файлу:

$ grep Port /etc/ssh/sshd_config
Port 22

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

Заключение

В заключение следует заметить, что в данной статье были рассмотрены лишь самые общие и распространённые неполадки, связанные с подключением по SSH. Обычно это легко выявляемые и быстро устраняемые ошибки.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Настройка брандмауэра для SSH в Linux

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

Конфигурационный файл OpenSSH находится в /etc/ssh/sshd_config — для просмотра без комментариев следует выполнить команду(ы):

$sudo grep -v '^#' /etc/ssh/sshd_config | grep -v '^$'

1. Настройка Брандмауэра (netfilter) для SSH и тырем порт

По умолчанию для SSH соединения, используется порт ТСP-порт 22. Забегая перед следует сказать, что многие рекомендует его поменять, но я так не думаю. Смена порта не поможет, «любой» сканер без труда отыщет ваш порт куда вы его не запрятали. Способ смены порта хорошо известен и Хакеры пишут соответствующие скрипты. Ниже будут приведены меры безопасности, прочитав их вы можете решить стоит ли менять порт или нет. Чтобы узнать какой порт слушает демон (sshd) на сервере, нужно выполнить команду:

$ sudo grep -w 'Port' /etc/ssh/sshd_config

#Port 22

Применив директиву Port поменяв значение, вы укажете демону (sshd) порт который нужно слушать;

Port 8822

Теперь демон (sshd) будет слушать порт 8822, для подключения к серверу, нужно воспользоваться на клиентской машине командой:

$ ssh -p8822 [email protected]

Ключ ‘-p‘ указывает порт, вместо user пишем имя пользователя, 127.0.0.1 меняем на IP своего сервера.

C портами разобрались, теперь нужно настроить брандмауэр. Можно воспользоваться средствами TUI дистрибутива.

Внимание! Будьте внимательны и последовательны в ваших действиях ! Неправильные действия могут привести к потере удалённого доступа.

Для Red-Hat based:

$ sudo yum install iptables system-config-securitylevel-tui

$ sudo system-config-securitylevel-tui

Нужно открыть порты (SSH) ТСP-22, UDP-22 или соответственно открыть порт который указали в директиве Port

Для SuSE:

$ sudo yast

Заходим в /Безопасность и пользователи/ Брандмауэр / Разрешённые службы — добавляем «Сервер Secure Shell», если вы указали порт директивой Port то / Брандмауэр / Разрешенные службы /Дополнительно и добавляем порт TCP и UDP .

Для «ручной настройки» следует внимательно ознакомиться с правилами iptables и настройкой брандмауэра вашего дистрибутива.

Приведу пример открытия портов простыми правилами:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

iptables -A OUTPUT -p udp --sport 22 -j ACCEPT

Внимание ! Следует понимать, что к примеру SuSEfirewall2 генерирует правила для iptables из конфигурационного файла /etc/sysconfig/SuSEfirewall2, в каждом дистрибутиве есть свои особенности управления брандмауэром.

2. Убираем «рута» и ещё кое что

Во многих дистрибутивах доступ «суперпользователю» по SSH открыт, это не совсем безопасно. За этим следит директива PermitRootLogin, чтобы посмотреть состояние:

$ sudo grep -w 'PermitRootLogin' /etc/ssh/sshd_config

PermitRootLogin no

#the setting of "PermitRootLogin without-password"

В примере показано, что значение директивы PermitRootLogin является no, значит что, авторизация под root -ом запрещена. Стоит отметить, в большинстве случаях когда доступ разрешён для «суперпользователя» то вывод команды:

$ sudo grep -w 'PermitRootLogin' /etc/ssh/sshd_config

#PermitRootLogin yes

#the setting of "PermitRootLogin without-password

Это значит авторизация под root возможна, следует PermitRootLogin придать значения no.

По умолчанию доступ к серверу разрешён всем пользователям. Что бы изменить ситуацию нам в помощь служат директива AllowUsers

AllowUsers:

AllowUsers luser1 luser2 luser4

Приведены пользователи через пробел, которым разрешён доступ.

Другой пример:

AllowUsers luser*

Будет разрешён доступ пользователям у кого имя начинается на luser.

Для разрешения групп(ы) служит директива AllowGroups :

AllowGroups luser fuser

Перечислены разрешённые группы через пробел.

Таким образом мы запретили «root» и указали каким именно пользователям/группам разрешён доступ.

3. Делаем вход по ключу

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

$ cd ~/.ssh

$ ssh-keygen -t rsa

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

• id_rsa — приватный ключ, клиентская часть
• id_rsa.pub — публичный ключ для сервера

Теперь нужно перенести ключ id_rsa.pub на сервер в файл ~/.ssh/authorized_keys делаем:

$ scp ~/.ssh/id_rsa.pub IP_сервера:\

~/.ssh/authorized_keys2

Для корректной работы нужно на северной части добавить или изменить параметры в /etc/ssh/sshd_confi:

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile .ssh/authorized_keys

Для запрета авторизации по паролям, добавляем в /etc/ssh/sshd_confi:

PasswordAuthentication no

PermitEmptyPasswords no

Будете внимательны, проверьте конфигурации, для вступления изменений в силу нужно сделать рестарт службы(демона) sshd:

$ sudo /etc/init.d/sshd restart

4. Защита SSH

Для защиты от перебора пароля и назойливых «брутфорсеров», можно и нужно использовать denyhostdenyhosts;

Для SUSE:

$ sudo zypper ar http://download.opensuse.org/repositories/\

network:/utilities/openSUSE_11.0/network:utilities.repo

$ sudo chkconfig denyhosts on

$ sudo rcdenyhosts start

Для Debian-based:

$ sudo apt-get install denyhosts

$ sudo/etc/init.d/denyhosts start

Для Red-Hat based:

$ sudo yum install denyhosts

$ sudo chkconfig denyhosts on

$ sudo service denyhosts start

После установки denyhost и запуска, все надоевшие клиенты будут посылаться в /etc/hosts.deny блокироваться.

Следует занести свой IP в файл /etc/hosts.allow — разрешённые адреса.

5. Советы для админов

Создаём директорию ~/bin туда будем складывать скрипты :

$ mkdir ~/bin 

Убеждаемся что в вашем профиле bash, переменная PATH содержит ~/bin.

$ echo $PATH

Пишем скрипт, делаем исполняемым:

$ vim ~/bin/gosrv.sh

#!/bin/bash


#file:gosrv.sh

ssh user@ваш_IP

$ chmod a+x ~/bin/gosrv.sh

Теперь можем набрав gosrv.sh подключаться к серверу.

Как делать sudo это баян, расскажу как сделать автодополнение после sudo. Вставляем в ~/.bashrc:

complete -cf sudo

linux — подключиться к порту localhost хоста 22: в соединении отказано

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

2. Авторизоваться
   зарегистрироваться

3. текущее сообщество
   

.

capistrano 3 порта ssh, но 22 все еще используется

Переполнение стека

1. Около

2. Продукты

3. Для команд

1. Переполнение стека
   Общественные вопросы и ответы

2. Переполнение стека для команд
   Где разработчики и технологи делятся частными знаниями с коллегами

3. Вакансии
   Программирование и связанные с ним технические возможности карьерного роста

4. Талант
   Нанимайте технических специалистов и создавайте свой бренд работодателя

5. Реклама
   Обратитесь к разработчикам и технологам со всего мира

6. О компании

Загрузка…

.