ssh что это linux
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
SSH (ч.1): Что такое SSH. Утилиты SSH
Оглавление
Что такое и для чего нужен SSH
SSH — это набор программ, которые позволяют выполнить вход на удалённую машину для выполнения команд на ней. Он предназначен для обеспечения защищённой зашифрованной связи между двумя узлами через незащищённую сеть. Соединения X11, произвольные порты TCP и сокеты домена UNIX также могут быть переадресованы по защищённому каналу. В SSH входят программы, которые дополнительно позволяют передавать файлы по зашифрованному соединению.
SSH несёт в себе различные улучшения безопасности, среди них аутентификация пользователя/хоста, шифрование данных и целостность данных, благодаря чему невозможны популярные атаки вроде подслушивания (сниффинга), DNS/IP спуфинга, подделка данных (data forgery), перехват соединения (connection hijacking) и т. д. Пользователям ftp, telnet или rlogin, которые используют протокол, передающий данные в виде открытого текста, крайне рекомендуется переключиться на SSH.
OpenSSH — это реализация с открытым исходным кодом протокола SSH, позволяющая шифровать соединение в сети посредством набора программ. Если вам хочется иметь SSH на Linux, вы можете установить OpenSSH, который состоит из сервера OpenSSH и клиентских пакетов.
Технология работает по принципу сервер-клиент. То есть на удалённой машине, на которой вы хотите выполнять команды, нужно запустить сервер OpenSSH. К этому серверу можно подключаться с помощью клиентов OpenSSH. На одном компьютере могут быть одновременно установлены и сервер и клиент. Их запуск и настройка выполняется независимо друг от друга.
Утилиты SSH
К серверным утилитам OpenSSH относятся:
Итак, на сервере основного внимания требует sshd, а программа sftp-server будет запущена автоматически по мере необходимости.
К клиентским утилитам OpenSSH относятся:
Это основные программы, которые могут понадобиться большинству пользователей для создания ключей, подключения к удалённой машине и при удалённом копировании файлов.
Следующие утилиты присутствуют в пакете OpenSSH, но не требуют от пользователя явного запуска или применяются редко:
Как установить OpenSSH
Для некоторых конфигураций служба OpenSSH установлена и включена по умолчанию. Как правило, это относится к системам, к которым затруднительно получить доступ иным способом, кроме как по SSH. Например, на хостингах VPS (виртуальных частных серверов) устанавливаемые системы практически всегда даже в минимальной конфигурации уже имеют установленную и запущенную службу SSH, поэтому после развёртывания нового сервера, клиенту достаточно подключиться используя присланные учётные данные.
В образах для ARM компьютеров, которые зачастую не имеют дисплея, как правило служба OpenSSH уже установлена и запущена.
В Debain и производных (Kali Linux, Linux Mint, Ubuntu), программы OpenSSH можно установить по отдельности, например, имеются пакеты для клиента и для сервера openssh-client и openssh-server. Либо можно установить метапакет ssh, который содержит и клиентскую, и серверную часть.
В Arch Linux клиент и сервер OpenSSH собраны в один пакет. Для установки OpenSSH в Arch Linux выполните:
В других дистрибутивах Linux поищите пакет openssh или ssh.
Управление службой OpenSSH
Клиент ssh запускается самим пользователем по мере необходимости.
Запуск службы OpenSSH требуется только на сервере.
OpenSSH поставляется с файлами служб systemd (смотрите также «Как использовать Systemctl для управления службами Systemd и юнитами») двух видов:
Таким образом, если вы хотите воспользоваться первой моделью (демон SSH всегда активен), то для запуска службы и добавления её в автозагрузку наберите следующие команды:
Они добавят демона SSH в автозагрузку и запустят его прямо сейчас.
Для второй модели (запуск SSH только по требованию), сделайте так:
sudo systemctl start sshd.socket
sudo systemctl enable sshd.socket
Для проверки статуса службы:
Либо если вы используете сокет:
systemctl status sshd.socket
Обратите внимание, что в разных дистрибутивах служба может называться ssh или sshd, следовательно, в приведённых выше и далее командах, используйте имена:
Как проверить журнал событий SSH службы
События SSH можно разделить на события:
Просмотреть логи SSH можно различными способами, один из вариантов (помните, что в некоторых системах служба называется ssh.service, без буквы d):
Например, для вывода последних 100 записей:
Также можно просмотреть события SSH с помощью:
Универсальная команда в независимости от имени службы:
Для вывода событий, связанных с подключением пользователей, другой информации, в том числе отладочной (зависит от настройки уровня подробности сообщений), можно посмотреть следующим образом:
Как увидеть неудачные попытки входа SSH
Если настроен вход по паролю, то для вывода неудачных попыток наберите команду:
Если настроен вход по публичному ключу, но не отключена возможность входа по паролю, то после неверного ключа, будет предоставлена возможности войти по паролю. Такие неудачные попытки входа по паролю можно найти такой же командой:
При неудачной попытке входа из-за неверного ключа, при уровне вербальности (LogLevel) по умолчанию (INFO) специальные сообщения не записываются в журнал. Подобные неудачные попытки можно обнаружить по записи «Connection closed by authenticating user», но она означает отключение на этапе аутентификации, независимо от способа аутентификации — по паролю или по ключу.
Если установить уровень вербальности на VERBOSE, то в журнале можно будет найти записи о неудачных попытках входа с помощью публичного ключа следующей командой:
Подробнее об этой настройке во второй часте.
Как просмотреть журнал подключений пользователей SSH
Чтобы показать подключения, когда вход был сделан по паролю:
Чтобы показать подключения аутентификации по публичному ключу:
Другой вариант просмотреть историю входов, это использовать следующую команду:
Памятка пользователям 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-сервера и т.д.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Руководство по команде SSH в Linux с примерами
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Установка клиента OpenSSH
Есть много SSH-клиентов, бесплатных и платных, и OpenSSH является наиболее широко используемым клиентом. Он доступен на всех основных платформах, включая Linux, OpenBSD, Windows и macOS. Клиент OpenSSH предустановлен в большинстве дистрибутивов Linux по умолчанию, однако если в вашей системе не установлен клиент ssh, вы можете установить его с помощью диспетчера пакетов.
Как получить доступ к удаленному серверу
Для подключения к удаленному компьютеру вам потребуется его IP-адрес или имя. Загрузите терминал или любой SSH-клиент и введите ssh, а затем IP-адрес:
При первом подключении к хосту вы увидите следующее сообщение:
Введите yes и нажмите Enter. Возможно, вам также потребуется ввести свой пароль.
Укажите имя пользователя для SSH-подключения
SSH использует текущего пользователя при доступе к удаленному серверу. Чтобы указать пользователя для SSH-соединения, выполните команду в следующем формате:
Примечание. Если вы столкнулись с ошибкой «Connection refused», обратитесь к нашему руководству, чтобы найти решения.
Используйте другой номер порта для SSH-соединения
По умолчанию сервер SSH прослушивает соединение на порту 22. Если настройка порта в файле конфигурации SSH была изменена, вам необходимо указать порт. В противном случае вы получите такую ошибку:
Генерация ключей SSH с помощью SSH Keygen
Чтобы повысить безопасность соединений SSH, сгенерируйте пару ключей с помощью утилиты keygen. Пара состоит из открытого и закрытого ключей. Открытый ключ может быть общим, а закрытый ключ должен оставаться в безопасности.
Пары ключей SSH используются для автоматической аутентификации клиентов на серверах. Когда вы создаете пару ключей SSH, больше не нужно вводить пароль для доступа к серверу.
На терминале хост-машины используйте эту команду для создания пары ключей:
Чтобы использовать настройки по умолчанию, нажмите Enter в ответ на запрос местоположения файла и парольной фразы.
Копировать открытый ключ SSH
Чтобы скопировать ключ на сервер, запустите эту команду на клиенте:
Вы также можете указать имя пользователя, если не хотите использовать текущего пользователя.
Введите пароль для аутентификации, когда его спросят. После этого вам больше не нужно будет использовать пароль для подключения к тому же серверу.
Копирование файла удаленно через SSH с помощью SCP
Вы можете безопасно копировать файлы по протоколу SSH с помощью инструмента SCP. Базовый синтаксис:
Например, чтобы скопировать файл sample3 на рабочий стол на удаленном сервере с проверкой имени пользователя, введите:
Выходные данные показывают сводку операции.
Редактировать файл конфигурации SSH
Используйте любой редактор по вашему выбору, чтобы отредактировать файл. Для внесения изменений вам потребуются права суперпользователя. В Linux мы используем vim.
В командной строке на удаленном хосте введите:
Введите пароль sudo, и оболочка откроет файл в редакторе, который вы использовали.
Перезапустить службу SSH
Когда вы вносите изменения в конфигурацию SSH, вам нужно будет перезапустить службу в Linux.
В зависимости от дистрибутива Linux выполните одну из следующих команд на машине, на которой вы изменили настройки:
Наконец, введите пароль, чтобы завершить процесс. В результате в следующем сеансе SSH будут использоваться новые настройки.
Выполнение команды на удаленном сервере с локального компьютера
Этот метод не создает новую оболочку. Вместо этого он запускает команду и возвращает пользователя в локальную подсказку. Вы можете создать файл, скопировать файлы или запустить любую другую команду SSH в этом формате.
Чтобы удаленно выполнить команду с локального компьютера, добавьте инструкцию к команде SSH. Например, чтобы удалить файл, введите:
Введите пароль, и файл на удаленном сервере будет удален без создания новой оболочки.
Параметры командной строки SSH
Инструмент SSH имеет множество дополнительных параметров. Ниже перечислены общие параметры SSH и соответствующие описания.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps