On-line журнал o Linux

В заметке рассмотрены такие методы как использования ssh без ввода пароля и стандартный парольный метод.

Взято с nixp.ru, автор: cebka.
Когда стали широко использоваться алгоритмы шифрования при передаче данных в сети, одной из первых задач стала организация безопасной оболочки.
Когда стали широко использоваться алгоритмы шифрования при передаче данных в сети, одной из первых задач стала организация безопасной оболочки. До этого существовала система rsh, которая позволяла определенным пользователям с определенных машин (между ними должны были быть доверительные отношения) работать на сервере с его оболочкой. Это практически то же самое, что и telnet-доступ. Но с развитием сетей стали видны вопиющие дыры rsh:

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

Поэтому сейчас rsh применяется в чрезвычайно редких случаях, например, при переносе данных между двумя попарно соединенными машинами (мне так пришлось работать с двумя машинами в разных комнатах). В основном стандартом де-факто стал ssh. Первая буква «s» означает безопасный (secure), что означает, что все данные, передаваемые через ssh шифруются, а значит, защищены от просмотра. Существует несколько версий протокола ssh, различающиеся используемыми алгоритмами шифрования и общими схемами работы. В настоящее время повсеместно используется протокол ssh версии два. Читать далее…

Ssh server для простых смертных (безопасное использованию сервера OpenSSH)

В первых заметках, SSH server для простых смертных, SSH server для простых смертных (авторизация по ключу) и SSH для простых смертных (возможности SSH), рассматривали установку и самую простую настройку SSH ( ssh server ) в этой заметки рассмотрим более детальную настройку сервера OpenSSH.
Для начало вспомним наши конфигурационные файлы:
/etc/ssh/sshd_config — конфигурационный файл сервера OpenSSH
/etc/ssh/ssh_config — конфигурационный файл клиентской части OpenSSH
~/.ssh/ - конфигурационная директория пользователей ssh.
Расмотрим несколько советов по безопасному использованию сервера OpenSSH.
Открываем наш конфиг и смотрим:
$ nano /etc/ssh/sshd_config
1. SSH порт, используемый по умолчанию: : TCP 22 ssh server, меняем так как многие brute forcing заточен под 22 порт и по крайней мере введет в заблуждения «кул хацкеров»
# What ports, IPs and protocols we listen for
Port 2280
Читать далее…

Дополнительные возможности SSH
Копирование файлов
из командной строки используется команда scp.
$ scp [file1] [user@host:file2]
некоторые опции:
-l limit — Ограничивает пропускную способность заданную в Kbit/сек.
-p — Сохраняет время модификации, время и права доступа и как у файла-оригинала.
-r — Рекурсивное копирование дерева каталогов с подкаталогами.
-v — Режим отладки. Принуждает scp выводить отладочную информацию об их работе. Это полезно для отладки соединения, аутентификации и проблем конфигурации.
-q — Отключает индикатор прогресса.
-P port — Определяет порт для связи с удаленной машиной(c ЗАГЛАВНОЙ) если был изменен дефолтовый порт.
Пример копирования файла smb.conf на удаленный хост в домашнию директорию пользывателя ceval в папку conf :
$ scp smb.conf ceval@192.168.XXX.XXX:/home/ceval/conf
Пример рекурсивное копирование, полность каталог:
$ scp -r ~/music user@host:/home/user/music
Читать далее…

SSH авторизация по ключу
Представим себе что у нас имеются десятки (о, ужас сотни машин) и к каждой надо запоминать различные пароли, а ставить один и тот же пароль не рекомендуется с точки зрения безопасности, также не удобно вводить пароль, например, в автоматических скриптах.
Поэтому SSH обеспечивает ещё один метод авторизации пользователя: по открытому ключу
Создаем ключи(открытый и закрытый):
$ ssh-keygen -t dsa

Generating public/private dsa key pair.
Enter file in which to save the key (/home/ceval/.ssh/id_dsa): key
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in key.
Your public key has been saved in key.pub.

После выполнения у нас появиться 2 файла, в идеале должны появиться в директории .ssh, у меня появились в ~/home/ceval возможно надо было указать путь при создании ключа (/home/ceval/.ssh):
key — приватный ключ, держать в секрете .ssh
key.pub — публичный ключ, необходимо будет положить на сервер
Если ключи создались ~/home/ceval перемещаем их в .ssh и на всю директорию ставим права — только чтение пользователю:
Читать далее…

В сети много документов по настройке удалённого управления в Линукс и БСД-системах, но часто в них умалчиваются простые (после прокуривания мануалов и гуглежа) вещи. Именно о них я расскажу в этом посте — может быть, кому поможет…
Установка SSH в Линукс на примере Debian(Ubuntu)
Итак, всё, что нам нужно для установки полного комплекта удалённого управления компьютером (клиент и сервер) давным-давно лежит в репозитории. Лёгким движением ставим пакет:
# apt-get install ssh
и ждём несколько мгновений, когда оно настроится.

На стороне клиента
Теперь надо поправить настройки, которые лежат в каталоге /etc/ssh — конфиг для клиента называется ssh-config, конфиг для сервера, соответственно, sshd-config. На своей, клиентской, стороне, настраиваем возможность приёма X11Forward, ищем и меняем ключи на:
......
ForwardX11 yes
ForwardX11Trusted yes
...........
Читать далее…

Эта статья не претендует на полный и расширенный howto, просто для своего же удобства решил все свои заметки, записки соединить воедино и пользоваться как шпаргалкой, возможно будут встречаться места(настройки) которые относятся лично ко мне и связаны только с моей спецификой эти места можно спокойна пропускать.
Забираем с офсайта себе образ netinst netinst, с экономим на времени выкачивания и трафике,все равно нужные нам пакеты будем ставить в ручную.
Ставим базовую систему и правим сетевые настройки, в моем случаи сервер будет иметь статический локальный адрес и реальный ip-получаемый по VPN
Работаем под su.
Читать далее…