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

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

Ниже на фото представлена консоль программы PuTTY. При подключении в любой программе нужно указывать хост (IP адрес) сервера и порт, на котором работает эта консоль. Обычно это 22-й порт.

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

Bitvise SSH Client

Также SSH отлично работают и в Bitvise SSH Client. Консоль точно такая же, но, кроме этого, в этой программе сразу открывается FTP.

Использовать можно что угодно. Главное, чтобы вам нравилось и всё работало. Принцип везде одинаковый.

Команды SSH для мониторинга системы

Команды SSH-консоли позволяют следить за сервером. Для этого достаточно набрать команду htop. Результатом будет изображение, которое вы видите ниже.

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

Графа Uptime показывает, сколько времени прошло с перезапуска системы. Если работа по администрированию сервера и контролю его состояния в целом выполнена профессионально, работать без перезагрузок он будет долго. Ведь если всё хорошо работает, то зачем перезапускать?

Здесь очень важной строчкой является Load Average с тремя значениями. Первое показывает среднюю нагрузку за последнюю минуту, второе - за последние 5 минут, третье - за последние 15 минут. Эта нагрузка определяется не так, как в стандартном диспетчере задач Windows.

Нагрузка может быть и больше 100. Даже больше 200. Система работает так: если показание за последнюю минуту будет меньше или равно 1 и при этом на компьютере одно ядро, то сервер справляется с нагрузкой. То есть здесь нужно учитывать соотношение количества ядер и цифр на экране. Если всё 1 к 1 или меньше, то это хорошо. Чем меньше значение, тем быстрее работает операционная система в целом.

Если нагрузка 4 на двухъядерном сервере, то нагрузка превышает в 2 раза возможности для стабильной работы. Старайтесь следить за этой цифрой. Если нагрузка большая, то постарайтесь оптимизировать работу сервера и того, что там работает.

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

Использовать команду htop может любой пользователь на сервере. Но смотреть нагрузку и запросы всех баз данных всех пользователей может только root. Для этого нужно войти на сервер через SHH и ввести команду mytop.

Здесь отображаются все текущие запросы с подробной информацией:

• ID запроса (чем дольше работает сервер, тем больше будет цифра);
• пользователь, который выполняет запрос;
• хост, где выполняется запрос;
• база данных;
• сколько времени выполняется запрос;
• сам запрос.

Самое важное здесь - время исполнения. Самые длинные процессы находятся внизу. Если вы видите, что какой-то mysql-запрос выполняется пару минут, то это ненормально. Нажмите кнопку k (от слова kill) и введите ID. В итоге вы сможете завершить запрос. Убейте таким образом все долгие запросы и сможете разгрузить сервер.

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

Основные команды Linux

Существуют различные команды SSH. У всех разное назначение. Например:

• для работы с файлами;
• для отображения системной информации;
• для управления процессами;
• для архивации;
• для работы с сетью;
• для работы с mysql;
• для поиска;
• для установки прав доступа на файлы;
• для установки пакетов.

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

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

Работа с файлами

Обратите внимание на то, что пути в командах надо писать исходя из того, где вы находитесь. Например, команда ls даст список текущей директории. Переходы по папкам посредством cd можно делать сразу в нужную, а не по одной.

Всегда смотрите на пути, которые вы пишете в командах. Также можно использовать "маски". Например, удалить все файлы txt можно, введя команду rm *.txt. Под звездочкой понимается что угодно, главное, чтобы в конце было.тхт.

Архивация файлов

Чтобы ознакомиться с этим вопросом, изучите фото ниже.

Системная информация

Основные команды приведены на фото.

Установка программ

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

Например, команды htop и mytop изначально в комплекте не идут. Их нужно устанавливать. Для этого вводим sudo apt-get install htop.

Устанавливать нужно из пользователя root. У других недостаточно прав.

Принцип установки одинаковый для всех программ. Просто в конце меняется вместо htop на нужную вам утилиту (для дальнейших команд).

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

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

Оглавление:

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

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

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

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

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

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

Копирование ключа на сервер

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id "-p 443 user@server" (внимание на кавычки).

Ключ сервера

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся - это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль - то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server . При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1 .

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub . Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

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

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

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

Scp path/myfile [email protected]:/full/path/to/new/location/

Обратно тоже можно:
scp [email protected]:/full/path/to/file /path/to/put/here

Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб - предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

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

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

sshfs

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере - с него в этой статье показываются картинки) на мой ноут:

#!/bin/bash sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user . Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет - авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path , однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.

Удалённое исполнение кода

Ssh user@server ls /etc/

Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:
ssh user@server -t remove_command

Кстати, мы можем сделать что-то такого вида:
ssh user@server cat /some/file|awk "{print $2}" |local_app

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

Проброс 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).

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

Host * User root Compression yes

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

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

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

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает - его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:
ssh -D 8080 user@server

В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай - если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение - повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn Hostname desunote.ru User vasya Compression yes DynamicForward 127.1:8080 Port 443

(обратите внимание на «ленивую» форму записи localhost - 127.1, это вполне себе законный метод написать 127.0.0.1)

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

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

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая - «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук - А, а «сервер» - Б.

Задача : у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

Ssh -R 127.1:80:8.8.8.8:8080 [email protected]

Опция -R позволяет перенаправлять с удалённого (R emote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача . На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost"у.

Итоговая конфигурация: запросы на localhost:3333 на "A" должны обслуживаться демоном на localhost:3128 "Б".

Ssh -L 127.1:3333:127.1:3128 [email protected]

Опция -L позволяет локальные обращения (L ocal) направлять на удалённый сервер.

Задача : На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

Ssh -L 192.168.0.2:8080:10.1.1.1:80 [email protected]

Вложенные туннели

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:
ssh -L 192.168.0.2:8080:127.1:9999 [email protected] ssh -L 127.1:9999:127.1:80 [email protected]

Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси

Если предыдущий пример вам показался простым и очевидным, то попробуйте догадаться, что сделает этот пример:
ssh -D 8080 -R 127.1:8080:127.1:8080 [email protected] ssh -R 127.1:8080:127.1:8080 [email protected]

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

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

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели - либо ssh разрешён (читай - делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации

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

Повторю картинку:

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал [email protected] на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

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

Вызов выглядит так:

Ssh -A [email protected] ssh [email protected]

Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

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

Есть ещё более могучий метод - он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет - взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

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

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

Ssh/config:
Host raep HostName 10.1.1.2 User user2 ProxyCommand ssh -W %h:%p [email protected]

Ну а подключение тривиально: ssh raep .

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить - да, может. Но если разрешил - пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для [email protected], так и в [email protected]

Разумеется, подключение можно оснащать всеми прочими фенечками - прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.
туннелирование ssh Добавить метки

SSH (secure shell) – это программа, позволяющая получить защищённый доступ к удалённым файловым системам [в Wikipedia дано более точное определение, прим.пер.] . Не все знают, что SSH обладает рядом дополнительных мощных возможностей, таких как вход без запроса пароля, автоматическое выполнение комманд в удалённой системе и даже монтирование удалённых папок. В этой статье мы рассмотрим эти, а также некотороые другие возможности SSH. SSH работает по принципу клиент-сервер. Это значит, что на сервере, к которому мы хотим подключиться, должен быть запущен демон SSH. В современных дистрибутивах Linux сервер SSH, как правило, установлен по умолчанию. Сервер запускается командой типа /etc/init.d/ssh start . По умолчанию он ожидает соединений на порту 22, так что если вы используете фаервол, убедитесь, что этот порт открыт. После установки и запуска SSH сервера мы можем удалённо подключиться к нему. Чтобы войти пользователем user1 на сервер remote_server (который указывается через доменное имя или IP адрес) нужно воспользоваться следующей простой командой:

Ssh user1@remote_server

После ввода пароля для доступа к удалённой машине, появится изменённое приглашение для ввода команд, которое выглядит следующим образом:

User1@remote_server:~$

Это означает что мы успешно произвели вход и сейчас работаем в окружении удалённого сервера. Теперь каждая команда будет выполняться на удалённом сервере, с привелегиями того пользователя, под которым мы вошли (в данном случае user1 ).

SCP – защищённое копирование файлов

SCP является составной частью пакета OpenSSH. Эта команда позволяет копировать файлы или папки с удалённого сервера (или на него), используя для этого протокол SSH. Благодаря использованию SSH, SCP является отличной заменой для небезопасного протокола FTP, которой широко используется в Интернете. Не все знают, что в FTP пароли передаются по сети в виде открытого текста, а это значит, что злоумышленники могут с лёгкостью перехватить их. Так что SCP это намного более надёжная альтернатива. Простейший пример использования SCP выглядит так:

Scp file.txt user1@remote_server:~/

При этом локальный файл file.txt будет скопирован на удалённый сервер и помещён в домашний каталог пользователя user1 . Вместо ~/ можно использовать другой путь, например /tmp , /home/public или любую другую папку, в которой пользователь user1 имеет права на запись.

Чтобы скопировать файл с удалённого сервера на локальный компьютер, используется другой синтаксис SCP:

Scp user1@remote_server:~/file.txt .

При этом файл file.txt , расположенный в домашнем каталоге пользователя user1 в удалённой системе, будет скопирован в локальную папку (в которой мы сейчас находимся).

Стоит обратить внимание на следующие параметры SCP:

-r – рекурсивное копирование папок (включая подкаталоги)

-P port – использовать нестандартный порт (по умолчанию 22) – этот параметр следует использовать если сервер ожидает соединения на нестандартном порту. Этот параметр может быть полезен при соединении из сети, защищённой фаерволом. Запуск SSH сервера на порту 443 (используемом для защищённых HTTP соединений) это лучший способ обойти ограничения, установленные сетевым администратором.

Графические интерфейсы для SCP

Если вам не нравится работать с консолью, то вы можете использовать графический (или псевдографический) клиент SCP. Midnight Commander – одна из программ, обладающая функциями SCP клиента (Меню → Правая панель/Левая панель → Shell-соединение). Nautilus и Konqueror также поддерживают SCP. Для подключения к удалённой системе в адресной строке надо ввести ssh://user1@remote_server:~/ . При этом файлы могут копироваться как если бы они были расположены локально. В среде MS Windows есть отличное приложение WinSCP . Его интерфейс очень похож на Total Commander. Кстати, существует плагин для Total Commander , позволяющий выполнять SCP подключения.

SSH без паролей – генерация ключей

Необходимость ввода пароля при каждом SSH соединении может сильно раздражать. С другой стороны, незащищённое удалённое соединение это огромный риск с точки зрения безопасности. Решением этой проблемы является авторизация с помощью пары из открытого (public) и секретного (private) ключей.

Пара ключей обычно генерируется с помощью команды ssh-keygen . Ниже показан результат выполнения такой команды. Возможно использование ключей RSA или DSA.

$ ssh-keygen -t rsaGenerating public/private rsa key pair. Enter file in which to save the key (/home/user1/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user1/.ssh/id_rsa. Your public key has been saved in /home/user1/.ssh/id_rsa.pub. The key fingerprint is: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Когда программа просит указать пароль для ключа, нужно просто нажать ENTER. При этом будет создан ключ без пароля. Имейте в виду, что это представляет угрозу безопасности, так как это понижает безопасность удалённой системы до уровня безопасности вашей локальной системы [злоумышленник, получивший доступ к секретному ключу, хранящемуся в вашей локальной системе, может воспользоваться им для доступа к удалённой системе - прим. пер.] . Поэтому делайте это на свой страх и риск. Когда ssh-keygen закончит свою работу, вы увидите, что были сгенерированы два ключа. Секретный ключ находится в /home/user1/.ssh/id_rsa . Его нельзя делать общедоступным ни при каких обстоятельствах. Второй ключ (открытый) находится в /home/user1/.ssh/id_rsa.pub , к нему можно предоставить публичный доступ.

Теперь, если мы хотим получить доступ к удалённой системе с нашего локального компьютера без запроса пароля (используя только эти два ключа), мы должны добавить информацию о нашем открытом ключе в файл authorized_keys , расположенный в папке ~/.ssh в удалённой системе. Для этого можно воспользоваться следующими командами:

$ scp /home/user1/.ssh/id_rsa.pub user1@remote_server:~/ $ ssh user1@remote_server $ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

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

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

Выполнение команд в удалённой системе

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

Один из интересных способов применения безпарольного входа это «удалённое оповещение». Допустим, что на удалённом сервере работает очень важный процесс, например веб-сервер Apache. Мы хотим получить уведомление, когда система начинает испытывать нехватку ресурсов (жёсткий диск переполнен или нагрузка на систему слишком высока). В этом случае мы можем отправить уведомление по электронной почте. Но помимо этого, мы можем выполнить удалённую команду, которая воспроизведёт звуковой сигнал в нашей локальной системе. Для этого можно воспользоваться, например, такой командой:

Ssh user1@local_server "play /usr/share/sounds/gaim/arrive.wav"

Эта команда, выполненная скриптом на удалённом сервере, произведёт безпарольный вход пользователем user1 на local_server (на котором мы обычно работаем) и воспроизведёт файл с помощью команды play (которая обычна доступна в Linux).

Перенаправление сеанса X11 (X forwarding) – удалённый запуск графических приложений

Одной из наимение известных функций SSH является перенаправление протокола X. Это позволяет запускать практически любое X приложение удалённо! Для этого всего лишь нужно добавить параметр -X при соединении с удалённым сервером:

Ssh -X user1@remote_server

После этого изображения всех запущенных X приложений будут перенаправлены на ваш локальный X сервер. В файле /etc/ssh/ssh_config можно включить постоянное использование перенаправления X11 (указав ForwardX11 yes ). Разумеется, чтобы этот параметр сработал, удалённый SSH сервер должен также поддерживать перенаправление X11. Настроить это можно отредактровав файл /etc/ssh/sshd_config . Однако в большинстве дистрибутивов Linux необходимые настройки уже выполнены по умолчанию.
Следующий пример показывает запуск одиночной команды с X перенаправлением:

Ssh -X user1@remote_server "psi"

При этом на удалённом сервере будет запущена программа PSI, а её изображение будет направлено на локальный экран.

Разумеется, скорость приложений, выполняемых удалённо, будет зависеть в первую очередь от скорости сетевого соединения. В локальной сети они будут работать практически без задержек (даже такие вещи как Totem, воспроизводящий фильм DivX). В случае интернет соединения, DSL линии будет достаточно, чтобы приложения типа Skype или Thunderbird работали без особых проблем.

SSHFS – монтирование удалённой папки

Работать с файлами, расположенными на удалённом сервере, через SSH может быть неудобно, особенно если приходится часто копировать различные файлы в обоих направлениях. Использование протокола fish в Midnight Commander или Konqueror является частичным решением, но fish работает медленне SSH и часто тормозит при копировании файлов. Идеальным решением было бы смонтировать удалённый ресурс, и работать с ним через SSH. И такая возможность есть, благодаря sshfs и проекту fuse.

Fuse это модуль ядра (недавно он был принят в официальную ветку 2.6), позволяющий непривилегированным пользователям монтировать различные файловые системы. SSHFS это программа, созданная самим автором fuse , которая позволяет монтировать удалённые папки или файловые системы, используя SSH. Суть проста – удалённая папка монтируются в папку локальной файловой системы. После этого все операции над этой папкой производятся как если бы это была обычная локальная папка, с той только разницей, что файлы перемещаются через SSH в фоновом режиме.

Установить fuse и sshfs в Ubuntu [и Debian - прим. пер.] очень просто:

# apt-get install sshfs

После этого остаётся только добавить пользователя, которому мы хотим предоставить право на монтирование файловых систем через SSH, в группу fuse (используя команду usermod -G -a fuse user1 [или adduser user1 fuse, что проще - прим. пер.] или вручную отредактировав файл /etc/group ). Также необходимо, чтобы был загружен модуль fuse :

# modprobe fuse

После этого, мы можем смонтировать удалённую папку с помощью sshfs :

Mkdir ~/remote_foldersshfs user1@remote_server:/tmp ~/remote_folder

Указанная выше команда смонтирует папку /tmp , расположенную на удалённом сервере, в папку ~/remote_folder на локальной машине. Копирование любых файлов в эту папку будет производится по сети с использанием SCP. Редактирование, создание и удаление файлов будет производится таким же образом.

По окончании работы с удалённой системой мы можем отмонтировать её:

Fusermount -u ~/remote_folder

Если мы постоянно работаем с этой папкой, то можно добавить её в таблицу /etc/fstab . При этом она будет автоматически монтироваться при загрузки системы, либо можно будет монтировать её вручную (при использовании параметра noauto ) без необходимости каждый раз указывать адрес удалённой папки. Пример записи в /etc/fstab :

Sshfs#user1@remote_server:/tmp /home/user1/remote_folder/ fuse defaults,auto 0 0

Если мы планируем использовать fuse и sshfs регулярно, то нужно добавить fuse в файл /etc/modules . Иначе придётся каждый раз загружать модуль fuse вручную.

Заключение

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

Ssh (secure shell) – это программа, позволяющая получить защищенный доступ к удаленным системам. Большинству из вас она должна быть хорошо знакома, однако не все знают, что ssh обладает рядом дополнительных мощных возможностей, таких как вход без запроса пароля, автоматическое выполнение комманд в удаленной системе и даже монтирование удаленных папок. Часть из них уже упоминалось в ранее выходивших статьях на эту тему, кое-что описывается на страницах нашего журнала впервые.

Для начала напомним самые базовые вещи, которые должны быть и так хорошо знакомы большинству IT-шников. Ну так, на всякой случай:) ssh работает по принципу клиент-сервер. Это значит, что на сервере, к которому мы хотим подключиться, должен быть запущен демон ssh. В современных дистрибутивах Linux сервер ssh, как правило, установлен по умолчанию. Сервер запускается командой типа /etc/init.d/ssh start. По умолчанию он ожидает соединений на порту 22, так что если вы используете файрвол, убедитесь, что этот порт открыт. После установки и запуска ssh- сервера мы можем удаленно подключиться к нему. Чтобы войти пользователем user1 на сервер remote_server (который указывается через доменное имя или IP-адрес) нужно воспользоваться следующей простой командой:

Ssh user1@remote_server

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

User1@remote_server:~$

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

SCP – защищенное копирование файлов

SCP является составной частью пакета OpenSSH. Эта команда позволяет копировать файлы или папки с удаленного сервера (или на него), используя для этого протокол ssh. Благодаря использованию ssh, SCP является отличной заменой для небезопасного протокола FTP, которой широко используется в Интернете.

Простейший пример использования SCP выглядит так:

Scp file.txt user1@remote_server:~/

При этом локальный файл file.txt будет скопирован на удаленный сервер и помещен в домашний каталог пользователя user1. Вместо ~/ можно использовать другой путь, например /tmp, /home/public или любую другую папку, в которой пользователь user1 имеет права на запись.
Чтобы скопировать файл с удаленного сервера на локальный компьютер, используется другой синтаксис SCP:

Scp user1@remote_server:~/file.txt .

При этом файл file.txt, расположенный в домашнем каталоге пользователя user1 в удаленной системе, будет скопирован в локальную папку (в которой мы сейчас находимся).

Стоит обратить внимание на следующие параметры SCP:

R – рекурсивное копирование папок (включая подкаталоги);

P port – использовать нестандартный порт (по умолчанию 22) – этот параметр следует использовать, если сервер ожидает соединения на нестандартном порту. Этот параметр может быть полезен при соединении из сети, защищенной файрволлом. Запуск SSH-сервера на порту 443 (используемом для защищенных HTTP-соединений) - это лучший способ обойти ограничения, установленные сетевым администратором.

графические интерфейсы для SCP

Если вам не нравится работать с консолью, то вы можете использовать графический (или псевдографический) клиент SCP. Midnight Commander – одна из программ, обладающая функциями SCP-клиента (Меню > Правая панель/Левая панель > Shell-соединение). Nautilus и Konqueror также поддерживают SCP. Для подключения к удаленной системе в адресной строке надо ввести ssh://user1@remote_server:~/. При этом файлы могут копироваться, как если бы они были расположены локально. В среде MS Windows есть отличное приложение WinSCP. Его интерфейс очень похож на Total Commander. Кстати, существует плагин для Total Commander, позволяющий выполнять SCP-подключения.

ssh без паролей – генерация ключей

Необходимость ввода пароля при каждом ssh-соединении может сильно раздражать. С другой стороны, незащищенное удаленное соединение - это огромный риск с точки зрения безопасности. Решением этой проблемы является авторизация с помощью пары из открытого (public) и секретного (private) ключей.

Пара ключей обычно генерируется с помощью команды ssh-keygen. Ниже показан результат выполнения такой команды. Возможно использование ключей RSA или DSA.

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key
(/home/user1/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in
/home/user1/.ssh/id_rsa.
Your public key has been saved in
/home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx

Когда программа просит указать пароль для ключа, нужно просто нажать ENTER. При этом будет создан ключ без пароля. Имейте в виду, что это представляет угрозу безопасности, так как это понижает безопасность удаленной системы до уровня безопасности вашей локальной системы (злоумышленник, получивший доступ к секретному ключу, хранящемуся в вашей локальной системе, может воспользоваться им для доступа к удаленной системе - прим. пер.). Поэтому делайте это на свой страх и риск. Когда ssh-keygen закончит свою работу, вы увидите, что были сгенерированы два ключа. Секретный ключ находится в /home/user1/.ssh/id_rsa. Его нельзя делать общедоступным ни при каких обстоятельствах. Второй ключ (открытый) находится в /home/user1/.ssh/id_rsa.pub, к нему можно предоставить публичный доступ.

Теперь, если мы хотим получить доступ к удаленной системе с нашего локального компьютера без запроса пароля (используя только эти два ключа), мы должны добавить информацию о нашем открытом ключе в файл authorized_keys, расположенный в папке ~/.ssh в удаленной системе. Для этого можно воспользоваться следующими командами:

$ scp /home/user1/.ssh/id_rsa.pub user1@remote_server:~/
$ ssh user1@remote_server
$ cat ~/id_rsa.pub >> ~/.ssh/authorized_keys

Обратите внимание, что третья команда выполняется на удаленном сервере. После этой процедуры все действия, выполняемые на удаленном сервере через ssh, не будут требовать ввода пароля. Это позволит существенно упростить нашу работу с удаленным сервером.

Обратите внимание, что если вам нужен беспарольный доступ с удаленного сервера на локальный, аналогичная процедура должна быть проведена с удаленного сервера. Авторизация с использованием ключей - это односторонний процесс. Секретный ключ может авторизовать публичный, но не наоборот.

выполнение команд в удаленной системе

Теперь, когда мы можем войти в удаленную системы без пароля, почему бы не выполнить несколько удаленных команд? В некоторых случаях это может быть полезно, например, когда нам нужно выполнять некоторую команду ежедневно. Раньше мы не могли автоматизировать этот процесс, так как требовался ручной ввод пароля (или указание его в виде простого текста, что является небезопасным).

Один из интересных способов применения беспарольного входа - это «удаленное оповещение». Допустим, что на удаленном сервере работает очень важный процесс, например веб-сервер Apache. Мы хотим получить уведомление, когда система начинает испытывать нехватку ресурсов (жесткий диск переполнен или нагрузка на систему слишком высока). В этом случае мы можем отправить уведомление по электронной почте. Но помимо этого, мы можем выполнить удаленную команду, которая воспроизведет звуковой сигнал в нашей локальной системе. Для этого можно воспользоваться, например, такой командой:

Ssh user1@local_server "play /usr/share/sounds/gaim/arrive.wav"

Эта команда, выполненная скриптом на удаленном сервере, произведет беспарольный вход пользователем user1 на local_server (на котором мы обычно работаем) и воспроизведет файл с помощью команды play (которая обычна доступна в Linux).

X forwarding - удаленный запуск графических приложений

Одной из наименее известных функций ssh является перенаправление протокола X. Это позволяет запускать практически любое X приложение удаленно! Для этого всего лишь нужно добавить параметр -X при соединении с удаленным сервером:

Ssh -X user1@remote_server

После этого изображения всех запущенных X-приложений будут перенаправлены на ваш локальный X-сервер. В файле /etc/ssh/ssh_config можно включить постоянное использование перенаправления X11 (указав ForwardX11 yes). Разумеется, чтобы этот параметр сработал, удаленный ssh-сервер должен также поддерживать перенаправление X11. Настроить это можно, отредактровав файл /etc/ssh/sshd_config. Однако в большинстве дистрибутивов Linux необходимые настройки уже выполнены по умолчанию.

Следующий пример показывает запуск одиночной команды с X перенаправлением:

Ssh -X user1@remote_server "psi"

При этом на удаленном сервере будет запущена программа PSI, а ее изображение будет направлено на локальный экран.

Разумеется, скорость приложений, выполняемых удаленно, будет зависеть в первую очередь от скорости сетевого соединения. В локальной сети они будут работать практически без задержек (даже такие вещи, как Totem, воспроизводящий фильм DivX). В случае интернет-соединения, DSL-линии будет достаточно, чтобы приложения типа Skype или Thunderbird работали без особых проблем.

sshfs - монтирование удаленной папки

Работать с файлами, расположенными на удаленном сервере, через ssh может быть неудобно, особенно если приходится часто копировать различные файлы в обоих направлениях. Использование протокола fish:// в Midnight Commander или Konqueror является частичным решением, но fish работает медленнее, чем ssh, и часто тормозит при копировании файлов. Идеальным решением было бы смонтировать удаленный ресурс и работать с ним через ssh. И такая возможность есть благодаря sshfs и проекту fuse.

Fuse - это модуль ядра (недавно он был принят в официальную ветку 2.6), позволяющий непривилегированным пользователям монтировать различные файловые системы. Sshfs - это программа, созданная самим автором fuse, которая позволяет монтировать удаленные папки или файловые системы, используя ssh. Суть проста - удаленная папка монтируются в папку локальной файловой системы. После этого все операции над этой папкой производятся, как если бы это была обычная локальная папка, с той только разницей, что файлы перемещаются через ssh в фоновом режиме. После установки программы остается только добавить пользователя, которому мы хотим предоставить право на монтирование файловых систем через ssh, в группу fuse (используя команду

# usermod -G -a fuse user1

# adduser user1 fuse

или вручную отредактировав файл /etc/group. Также необходимо, чтобы был загружен модуль fuse:

# modprobe fuse

После этого, мы можем смонтировать удаленную папку с помощью sshfs:

Sshfs user1@remote_server:/tmp ~/remote_folder

Указанная выше команда смонтирует папку /tmp, расположенную на удаленном сервере, в папку ~/remote_folder на локальной машине. Копирование любых файлов в эту папку будет производиться по сети с использованием SCP. Редактирование, создание и удаление файлов будет производиться таким же образом.

По окончании работы с удаленной системой мы можем отмонтировать ее:

Fusermount -u ~/remote_folder

Если мы постоянно работаем с этой папкой, то можно добавить ее в таблицу /etc/fstab. При этом она будет автоматически монтироваться при загрузки системы, либо можно будет монтировать ее вручную (при использовании параметра noauto) без необходимости каждый раз указывать адрес удаленной папки. Пример записи в /etc/fstab:

Sshfs#user1@remote_server:/tmp /home/user1/remote_folder/ fuse defaults,auto 0 0

Если мы планируем использовать fuse и sshfs регулярно, то нужно добавить fuse в файл /etc/modules. Иначе придется каждый раз загружать модуль fuse вручную.

заключение

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

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

Перед тем, как вы начнете это руководство, вам понадобится следующее:

• Доступ к Терминалу.

Шаг 1 - Доступ к удаленному серверу

SSH – это сетевой протокол прикладного уровня (с англ. Secure Shell или Безопасная Оболочка) . Это протокол, используемый для безопасного доступа к удаленному серверу или системе.

Вот одна из базовых SSH команд, которую вы должны использовать:

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

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

Вот и все, вы подключены к серверу и можете продолжить чтение данного руководства о базовых SSH командах! Если вы хотите выйти из удаленного сервера и вернуться обратно к вашему локальному компьютеру, просто впишите exit в командной строке.

Более детальное руководство о том, как присоединиться к VPS используя Putty SSH (ssh-клиент) вы можете найти .

Шаг 2 - Базовые SSH команды

В этом шаге мы пройдемся по самым основным/часто используемым SSH командам, о которых вам следует знать!

ВАЖНО! Это применимо для всех команд в оболочке. При написании аргумента возле команды, к примеру, cd ‘Folder One’ (где имя папки состоит из двух раздельных слов), вы должны ввести имя папки в кавычках. Команда cd Folder One (без кавычек) работать не будет, потому что система воспримет название как два аргумента (“Folder” и “One” ).

1. ls – Это команда используется для отображения всех файлов и каталогов. Мы рекомендуем использовать ее с опцией -l, она будет выглядеть так ls -l, в таком случае все файлы будут отображены в удобной для вас форме с подробными деталями и информацией о них. Еще одна полезная опция -a, она отобразит все файлы, включая скрытые файлы/папки (файлы с расширением перед ними, к примеру: каталог .ssh ).
2. cd – Это команда используется для перемещения между каталогами (cd расшифровывается как “change directory” – “сменить каталог”). После отображения всех файлов и каталогов при помощи команды ls, вы сможете выбрать каталог, в который желаете перейти. К примеру, есть каталог home в который вы хотите войти. Введите команду cd home, и вы мгновенно измените ваше текущее расположение на каталог “home”. Можете попробовать снова ввести команду ls, чтобы увидеть, что информация выводимая на экран изменилась. Также можете вписать полный путь до нужного каталога, если он расположен на несколько уровней глубже. Для примера можно использовать: cd home/TestDirectory/AnotherDirectory. В таком случае вы будете перемещены в каталог под названием “AnotherDirectory”. Используйте команду cd .. (cd пробел и две точки) для перехода на уровень выше (в нашем примере мы вернемся в “TestDirectory” из каталога “AnotherDirectory”).
3. mkdir – Эта команда используется для создания новых каталогов (расшифровывается как “make directory” – “создать каталог”). Она просто создает каталог с выбранным именем, к примеру, mkdir NewFolder создаст папку с именем “NewFolder” в текущем каталоге.
4. touch – Эта команда используется для создания файлов с выбранным расширением. К примеру, touch NewFile.txt создаст новый “txt” файл “NewFile” в текущем каталоге (расширение может быть любым, и даже без наличия такового, к примеру, touch NewFile.
5. rm – Эта команда используется для удаления выбранного файла или каталога. К примеру, rm NewFile удалит ранее созданный файл с названием “NewFile”. Если вы хотите удалить каталог и все что находится внутри него, используйте rm -r NewFolder, это удалит каталог “NewFolder” и все файлы внутри него.
6. cat – Эта команда используется для отображения содержимого файла. К примеру, cat info.txt отобразит содержимое этого файла на экран. Другой пример, cat info.txt info2.txt > mergedinfo.txt объединит вместе два файла (“info.txt” и “info2.txt”) и запишет объединенное содержимое в файл “mergedinfo.txt”.
7. pwd – Эта команда покажет ваше текущее положение в файловой системе. К примеру, написав pwd, на выходе вы получите что-то вроде: “home/user/public_html”.
8. cp – Эта команда используется для копирования файлов и каталогов. Синтаксис таков:

Обычно вместо source вы пишите файл, который вы хотите скопировать. Вместо dest , пишите расположение файла/папки. Сейчас, если вы напишите название расположения, которого не существует, к примеру, у вас исходный файл oldfile.txt и вы пишите расположение файла newfile.txt , команда просто скопирует файл и вставит его с новым именем.

В дополнение, имеется несколько опций, которые вы можете использовать с командой cp:

• cp -f source dest – Принудительно проводит процедуру копирования удаляя целевой файл при необходимости.
• cp -i source dest – Даст предупредительное сообщение перед перезаписью файла.
• cp -u source dest – Обновит опции. Скопирует файл только в том случае, если исходный файл новее, чем целевой.
• cp -n source dest – Не будет копировать файл, если он уже существует (не перезапишет).
• cp -a source dest – Эта опция будет архивировать файлы.

1. mv – Эта команда работает так же как и cp, но вместо копирования файла, она его перемещает. Эту команду также можно использовать для переименования файла. Если мы возьмем тот же пример, что и в случае с командой cp, (в нашем текущем каталоге, у нас есть файл oldfile.txt ) и мы пишем эту команду: mv oldfile.txt newfile.txt она попросту переименует файл oldfile.txt в newfile.txt .
2. grep – Это команда проводит поиск в заданном файле/каталоге. К примеру: grep ‘word’ file будет проводить поиск файла со словом ‘word’ в файле под названием “file” . grep покажет всю строку из файла, если фраза найдена. К примеру, есть строка ‘All in all it’s just another word in a sentence ’ в файле под названием “file” , используя команду grep ‘word’ file, эта строка будет выделена на экране, так как было найдено слово word.
3. find – Сейчас эта команда используется для поиска файлов по папкам, которые подходят выбранным критериям (название, размер, тип файла). К примеру, команда: find . -name “*.html” будет выводить все файлы в текущем каталоге, которые имеют окончание/расширение “.html” (надо отметить, что мы использовали знак ” * “ в нашей команде, он говорит системе о том, что неважно какое название имеет файл перед “.html”, важно лишь то, что он заканчивается на “.html”.
4. vi/nano – Эта команда используется для входа в текстовый редактор. К примеру: nano newfile создаст либо новый файл с именем “newfile” и войдет в редактор nano, либо начнет редактирование существующего файла “newfile” (если он имеется) с помощью того же редактора. Те же вещи применимы и для команды vi, которая открывает другой редактор под названием “vi”.

1. history – Эта команда используется для отображения последних использованных вами команд. К примеру: history 20 отобразит 20 последних введенных команд в Терминале Linux.
2. clear – Эта команда очистит весь текст в окне Терминала .

Заключение

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