Alt linux установка ssh

Alt linux установка ssh

Получается так, что web-интерфейс к серверу доступен на клиентском компьютере, а если надо посмотреть содержимое какого-нибудь конфигурационного файла, надо пересаживаться к серверу. Это, конечно, неудобно. Хорошо бы и с клиентского (сисадминского) компьютера получить доступ к файлам сервера. Сделать это не просто, а очень просто.

Самая популярная технология для этого — SSH (Secure SHell). Она позволяет создать защищенное TCP-соединение между двумя компьютерами. Работа идет по принципу клиент-сервер.

В ALT Linux Office Server сервер ssh (компонент называется openssh) по умолчанию установлен, но настроен так, что сразу сделать ничего нельзя. Это необходимо для безопасности.

Доступ по SSH организуется разными способами — по паролю или по ключевым файлам. Что лучше, вопрос философский. Что легче украсть — пароль или файл? Для кражи пароля нужен вирус-троян или подглядывание, для кражи файла нужен кратковременный доступ к компьютеру. Гарантии безопасности нет нигде.

Откроем доступ по паролю. Для этого надо в конфиг-файле /etc/openssh/sshd_cofig раскомментировать строку:

После этого надо перезапустить службу:

# service sshd reload

При этом для пользователя root доступ все равно будет запрещен, и это правильно. За доступ суперпользователя отвечает параметр PermitRootLogin.

Сервер подготовлен, осталось подготовить клиент.

8.4.1. Доступ с компьютера под управлением Windows

Нам потребуется программа putty.exe. Получить ее можно на сайте http://www.putty.org. Программа эта автономная, так что держать ее можно хоть на рабочем столе.

Сначала выполним настройки, затем подключимся.

Открыв программу (рис. 8.2), надо зайти в раздел Translation и выбрать кодировку UTF-8. Затем в разделе Session надо ввести IP-адрес сервера, в строке Saved Sessions — произвольное имя сессии, а затем надо нажать кнопку Save. В дальнейшем можно выбирать эту сессию (ее настройки) кнопкой Load.

Рис. 8.2. Настройка программы putty.exe

Нажимаем клавишу Enter и получаем возможность ввести логин и пароль обычного пользователя (которого мы создали при установке сервера). Кстати в настройках putty можно задать и логин по умолчанию.

В результате получаем доступ в консоль сервера, и можем, к примеру, запустить MC (рис. 8.3).

Рис. 8.3. Удаленный доступ к серверу

Для системного администратора теперь уже не составит труда перейти в режим суперпользователя.

Для выхода из сессии надо набрать команду exit.

Вникнуть в тонкости SSH для ALT Linux можно здесь: http://heap.altlinux.org/modules/sshd/index.html.

8.4.2. Доступ с компьютера под управлением Linux

Если клиент работает под управлением Linux, можно использовать ту же программу putty.exe. Она работает под Wine, достаточно скопировать ее в каталог wine_c, и можно запускать. Единственная проблема — ее окно не может изменить размер.

Для Linux есть масса rpm-пакетов putty, Но в ALT Linux 4.1 Desktop с работой этой программы есть проблемы, результат гарантировать нельзя.

Проще использовать консоль и программу ssh. Нужно дать всего одну команду с указанием имени пользователя и адреса сервера, например:

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

Для копирования файлов есть еще один вариант — доступ к сетевой папке с помощью SSH. Для этого предусмотрен мастер. Выберите команду Система — Сетевые ресурсы. Щелкните значок Добавить сетевую папку. В окне мастера введите нужные параметры (рис. 8.4).

Рис. 8.4. Создание ярлыка для сетевой папки

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

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

Источник

Удалённый доступ и удалённое администрирование (OpenSSH)

Одна из самых распространённых задач, возникающих при работе в сети, — удалённый доступ к другим компьютерам, в том числе их удалённое администрирование. Технология SSH (Secure Shell) призвана предоставить возможность безопасного способа управления удалённой системой. Посторенная по клиент-серверной модели, она позволяет при помощи ssh клиента подключаться к ssh серверу, предоставляя командную оболочку для работы с удалённой системой.

SSH реализует соединение с удалённым компьютером, защищающее от:

• прослушивания данных, передаваемых по этому соединению;
• манипулирования данными на пути от клиента к серверу;
• подмены клиента или сервера путём манипулирования IP-адресами, DNS или маршрутизацией.

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

• Сжатие передаваемых данных.
• Туннелирование каналов внутри установленного соединения, в том числе соединений с X-сервером, что позволяет запускать графические приложения на удалённой машине.
• Широкая распространённость: существуют реализации SSH для самых различных аппаратных платформ и операционных систем.

OpenSSH — это включённая в дистрибутивы ALT Linux реализация SSH. Она представлена следующими пакетами:

• openssh-clients — клиентская часть (утилита ssh , sftp и др.).
• openssh-server — серверная часть (сервер sshd , sftp-server ).
• openssh — утилиты, необходимые для работы как клиентской, так и серверной части.

Пакет openssh-server в ALT Linux 4.0 Server устанавливается по умолчанию, позволяя непосредственно после установки системы воспользоваться возможностью удалённого администрирования.

В простейшем виде сеанс работы будет выглядеть следующим образом. Запускается ssh клиент ( ssh ) с указанием имени пользователя на удалённой системе (если оно отличается от локального) и имени машины (либо IP-адреса). На удалённой машине, естественно, должна быть настроена и работать серверная часть — sshd .

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

Аутентификация

Прежде чем начать удалённый сеанс работы, необходимо пройти процедуру аутентификации, аналогичную той, что происходит при непосредственной работе с физическим терминалом Linux-системы. Утилита sshd поддерживает различные способы аутентификации, наиболее часто используются два из них: аутентификация по паролю и аутентификация по ключу.

Параметры, относящиеся к способу аутентификации, а так же все прочие настройки sshd указываются в конфигурационном файле /etc/openssh/sshd_config . Для вcтупления в силу изменений, вносимых с конфигурационный файл, каждый раз после правки файла необходимо выполнять команду

Аутентификация по паролю

Аутентификации по паролю включается добавлением строки PasswordAuthentication yes в файл etc/openssh/sshd_config . Хотя пароль в этом случае и не передается по сети в открытом виде, всё же существует опасность подбора пароля. Поэтому не следует выбирать слишком простые пароли.

Аутентификация по ключу

Аутентификация по ключу включается строкой

в файле /etc/openssh/sshd_config . При использовании этой схемы аутентификации будет использоваться асимметричное шифрование, следовательно, необходимо сгенерировать пару ключей: секретный и публичный 1 .

Для генерации пары ключей на компьютере пользователя необходимо выполнить $ ssh-keygen с необходимыми параметрами, например:

На вопрос о файле для сохранения ключа нажать Enter (принять вариант по умолчанию). Будет задан вопрос, следует ли создать пароль к ключу. Поскольку ключи рекомендуется создавать с паролем, нужно указать свой пароль.

После генерации ключей образуются 2 файла:

/.ssh/id_dsa — секретный ключ, и

/.ssh/id_dsa.pub — публичный. Его предстоит поместить на удалённый сервер.

Следующим шагом содержимое файла id_dsa.pub неоходимо добавить в файл

/.ssh/authorized_keys2 на удалённой машине. Если под этой учётной записью будет входить один пользователь, файл id_dsa.pub можно просто скопировать, назвав его authorized_keys2 . Также можно воспользоваться утилиой ssh-copy-id :

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

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

Безопасность

При настройке sshd следует весьма щепетильно отнестись к вопросам безопасности. SSH — очень важная часть системы. Она является незаменимым помощником любого администатора Linux, предоставляя ему доступ к командной оболочке удалённой системы. Но как раз по этой же причине данная служба может стать и источником бед.

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

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

В качестве дополнительных мер, можно явно указать список пользователей, которым разрешена либо запрещена удалённая работа. За это отвечают параметры AllowUsers и DenyUsers в /etc/openssh/sshd_config .

Наконец, можно осложнить жизнь потенциальному злоумышленнику, отключив возможность удалённой регистрации в системе для суперпользователя ( root ). Для этого в /etc/openssh/sshd_config нужно добавить строку PermitRootLogin no .

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

За более детальной информацией по настройке sshd следует обращаться к руководству sshd_config(5) . Настройка клиентской части подробно описана в ssh_config(5) .

Источник

Доступ по SSH

С помощью SSH-сервера можно удаленно управлять сервером через консоль (ssh://-соединение) и передавать файлы (sftp-сервер).

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

На сервере переключаемся в режим суперпользователя:

И правим следующий файл:

Перед этим делаем на всякий случай бэкап конфига:

Потом, если что, удаляем измененный и восстанавливаем исходный:

В любом случае при изменениях этого файла стоит обязательно:

1. держать уже открытую рутовую сессию через достаточно надёжное соединение;
2. перезапустить sshd;
3. попытаться подключиться ещё одной рутовой сессией по ключу (либо пользовательской с поднятием привилегий, что несколько менее предпочтительно),

чтобы убедиться в том, что удалённый доступ к системе всё ещё функционирует.

Добавляем в конец файла(!) [1] конфигурацию, которая для заданного пользователя отключит интерактивный доступ и оставит только sftp до заданного каталога:

Обмен файлами [ править ]

Обмен файлами с сервером будет происходить по протоколу SSH.

Этот же каталог прописываем в ChrootDirectory.

Даем себе полные права:

Подключаем его на Workstation:

• Открываем Caja
• Файл > Соединиться с сервером:
  • IP
  • Тип: SSH
  • Папка: /home/files
  • Имя пользователя: petr (учетка на сервере, которой мы дали права)
  • Пароль: (соответствующий)
  • Можно поставить галочку «Добавить закладку»

Источник

Alt linux установка ssh

Создание и настройка входа через ssh

Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ. Предполагается что ssh-сервер запущен и имеет настройки, принятые по умолчанию в ALT Linux.

Содержание

Введение

ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.

Создание ключа

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

На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). Далее будет задан вопрос о пароле к ключу. Пароль нужно указать.

/.ssh появляются файлы

• id_ed25519 — секретный ключ
• id_ed25519.pub — публичный ключ

Настройка входа (на сервере)

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

/.ssh/authorized_keys добавить содержимое файла id_ed25519.pub . Если пользователь будет один входить под этой учётной записью, файл id_ed25519.pub можно просто скопировать, назвав authorized_keys. Также можно воспользоваться утилитой ssh-copy-id , если копировать вручную не хочется: ssh-copy-id user@host

Данные изменения проводятся в каталоге пользователя на сервере.

принадлежать файлы должны пользователю и его группе.

Пользователям XFCE может потребоваться включить явный запуск ssh-agent, чтобы его использовать:

Изменение вступит в силу после перелогина.

Проверка того, что ключ работает:
1. $ ssh-add
2. $ ssh другая_машина
При подключении не должен запрашиваться пароль.

Использование

Конфигурационный файл (у пользователя)

Для удобства в файле

/.ssh/config можно указать сокращение

и вызывать просто как

Можно добавить ещё настроек:

Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить

Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).

Настройка сервера

Инструкция по установке и настройке сервера ssh для администратора

Нужно установить пакет openssh-server, включить автоматический запуск при загрузке системы:

В файле /etc/openssh/sshd_config укажите строку AllowUsers с перечислением пользователей, имеющих право подключаться к системе.

А также рекомендуется выключить аутентификацию по паролю (исправить строчку PasswordAuthentication на):

Для вступления настроек в силу:

Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить

Управление сессиями

PAM session management в openssh той версии, которая находится в Сизифе и дистрибутивах, использует privilege separation и потому исполняется с правами пользователя, а не root. Как следствие,

• pam_mktemp не сможет создать подкаталог в /tmp/.private/ с нужными правами, если его там нет;
• pam_mkhomedir не сможет создать подкаталог с нужными правами, если его там нет;
• pam_limits не сможет увеличить лимиты сверх тех, что есть у процесса openssh.

В качестве объезда можно помещать эти модули в PAM account management.

Полезные советы

Предотвращение брутфорс-атак

• Можно пересадить sshd на нестандартный порт
• Целесообразно ограничить число «ожидающих» соединений, когда пароль еще не введен. Для этого, в файле /etc/openssh/sshd_config укажите строку

В этом случае у вас будут разрешены только 2 «ожидающих» соединения, и каждое следующее будет сброшено с вероятностью 70 %

• Для особо изощрённой защиты можно использовать knock.
• Можно ограничить число попыток средствами iptables:

Для оптимизации этого дела настроятельно рекомендуется завести цель LOGDROP.

В файл /etc/fail2ban/jail.d/customisation.local записать

В файле /etc/openssh/sshd_config параметру UseDNS задать значение no.

Настройка второго sshd

Копируем /etc/init.d/sshd и указываем через -f другой конфигурационный файл? Практика показывает, что надо менять весь набор: копировать /etc/init.d/sshd, /etc/sysconfig/sshd; (факультативно делать ссылки или копировать сам sshd, /etc/pam.d/sshd); изменять посредством /etc/sysconfig/sshd переменные PIDFILE, LOCKFILE, EXTRAOPTIONS.

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

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

Cisco IOS и SSH 6.6p1

Ошибка при подключении: SSH2 0: Client DH key range mismatch with max built-in DH key on server!

/.ssh/config (что бы не переопределять глобально у остальных пользователей) добавить:

т.е. diffie-hellman-group14-sha1 — на первое место.

Настройка входа по одноразовому паролю

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

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

В качестве инфраструктуры для одноразовых паролей мы возьмём Google Authenticator, ибо всё необходимое уже есть в репозиториях. Нам понадобятся два пакета: libpam-google-authenticator и libqrencode (без последнего можно обойтись). Если пакета google нет в репозитории вашей платформы, то его несложно собрать самому в хешере, у него почти нет зависимостей.

Итак, пакеты установлены. На время настройки рутовую консоль лучше держать открытой. Сначала создадим необходимые файлы у пользователя, который будет входить с одноразовым паролем. Входим под ним и выполняем:

Будут заданы следующие вопросы:

• Сделать токены зависимыми от времени — y
• Здесь, если вы поставили libqrencode, вам будет показан QR-код. В приложении Google Authenticator а

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

/.google_authenticator? — y

Запретить использование одного кода несколько раз — y

Расширить время действия кода с 1,5 минут до 4? — n

Запретить попытки входа чаще, чем 3 раза за 30 сек? — y

Всё, настройка для пользователя закончена. Идём ковырять систему (из-под рута, конечно).

Сначала OpenSSH. В /etc/openssh/sshd_config включаем вопрос-ответ:

И просим демона перечитать конфиг:

Отлично, с SSH закончили. Теперь правим соответствующие настройки PAM (они лежат в /etc/pam.d/sshd). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в pam.d/sshd, то независимо от порядка следования модулей, будет выводится только запрос на одноразовый пароль и всегда будет access denied.

Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их pam_tcb, причём он и сам умеет запрашивать пароль!

Решение очень простое — выкидываем userpass, вставляем на его место tcb без параметра use_first_pass. После этип манипуляций конфиг должен выглядеть так:

Весь остальной стек для auth выкидываем, ибо там тот же tcb и всякий ldap, который не нужен (если нужен, придётся перенести его сюда же).

Порядок следования модулей auth важен, при таком как в примере, сначала запрашивается пароль, затем всегда одноразовый код. Так невозможно понять, что именно неверно, и это хорошо для безопасности. Если хотите, чтобы авторизация обламывалась сразу, замените required на requisite у pam_tcb.

Источник