Как установить SSH с аутентификацией при помощи публичного ключа в Debian Etch

Пер. с англ., источник - здесь

Подготовительные замечания.

Это мини-HOWTO объясняет, как установить SSH-сервер в Debian Etch с аутентификацией при помощи публичного ключа (и опционально с отключением входа по паролю). SSH - прекрасный инструмент для удаленного управления компьютерами на базе Linux. Он надежен и безопасен.
Нет никакой гарантии, что все будет работать в вашем конкретном случае. Все эти настройки применимы для Debian и производных от него систем! На других системах могут иметь место незначительные отличия.

Установка SSH на сервер.

Во-первых, мы установим SSH на наш сервер. Мы можем сделать это с помощью этой команды: (Заметьте, что вы должны иметь привилегии root, чтобы сделать это!)

apt-get install ssh

Подготовка нашей клиентской системы.

Во-вторых, мы выполним некоторые подготовительные действия на нашей клиентской машине. Этот PC будет использоваться для подключению к серверу. Итак, SSH-сервер был уже установлен на различные машины. На вашей рабочей станции мы устанавливаем ssh-клиента (который мы используем для подключения к серверу). Заметьте, что установка программ требует привилегий root! Если вы не вошли в систему как root, пожалуйста сделайте это сейчас! (su root и затем напечатайте ваш пароль). Затем установите клиента:

apt-get install openssh-client

Переключитесь обратно к сеансу для вашего нормального пользователя (не root, соответственно). Затем введите эти команды по порядку:

mkdir ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh

Мы сгенерируем нашу пару ключей, публичный и секретный ключи. Публичный ключ размещается на сервере, а вы входите в систему с вашим секретным ключом. Когда попросят, введите вашу парольную фразу (она будет необходима для будующего входа в систему, так что помните ее!):

ssh-keygen -t rsa -C "A comment... usually an email is enough here..."

Теперь мы скопируем публичный ключ (который мы уже сгенерировали только что выше) на наш (удаленный) сервер. Удаленный пользователь не должен быть root! Измените не-root пользователя по умолчанию в качестве удаленного пользователя. (Обратите внимание на двоеточие в конце строки! Это важно.)

scp -p id_rsa.pub remoteuser@remotehost:

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

ssh remoteuser@remotehost
mkdir ~/.ssh
chmod 700 ~/.ssh
cat id_rsa.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
mv id_rsa.pub ~/.ssh
logout

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

rm id_rsa.pub

И затем пробуем войти опять:

ssh remoteuser@remotehost

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

Выключение аутентификации по паролю.

Отключение ее - хороший способ иметь надежную установку SSH. После этого вы можете войти в систему только с помощью пары ключей, так что будьте осторожны, не потеряйте их! Это совершенно необязательно, но безопасно для активации! Но до того, как сделать это, пожалуйста убедитесь, что аутентификация на основе ключей работает "из коробки". Сядьте перед сервером (то есть не входите удаленно, так как мы должны перезапустить SSH позже...) и введите эти команды вручную как root:

cd /etc/ssh
cp sshd_config sshd_config.orig
nano sshd_config

У вас появится на экране текстовый редактор nano с открытым главным конфигурационным файлом OpenSSH. Измените эти строки (не беспокойтесь, если любая из этих строк имеет отметку "#" в начале строки; если отметка есть, просто удалите решетку):

PermitRootLogin yes
PasswordAuthentication yes
UsePAM yes

На эти:

PermitRootLogin no
PasswordAuthentication no
UsePAM no

Теперь сохраните файл с помощью сочетания клавиш Ctrl + 0 и перезапустите SSH-сервер:

/etc/init.d/ssh restart

Будьте осторожны: если вы отключите аутентификацию по паролю, то вы не сможете зайти в систему с помощью паролей! Только аутентификация с помощью ключа будет доступна!

Использование аутентификации в squidGuard

Пер. с англ., источник - http://www.squidguard.org/Doc/authentication.html

Иногда удобно разрешить разным пользователям различный тип доступа. SquidGuard имеет возможность указать, основываясь на имени пользователя, к каким ресурсам этот пользователь может иметь доступ.
Имеется два различных способа, как установить аутентификацию пользователя: на основе имени, предоставленном прокси-сервером squid, или используя роли LDAP (это подразумевает, что либо вы используете squidGuard 1.2.1 и выше, или имеете squidGuard, пропатченный вами с помощью LDAP-патчей Криса Фрея.

1. Аутентификация с помощью имен пользователей прокси-сервера squid

Начнем по порядку: чтобы сделать это, вы должны настроить ваш squid для аутентификации ваших пользователей. Простой способ добавить пользовательскую аутентификацию - использование старой утилиты ncsa_auth. Добавляя следующие три строки в ваш squid.conf, вы можете включить аутентификацию:

auth_param basic program /usr/libexec/squid/ncsa_auth \ /etc/squid/squid.passwd
acl password proxy_auth REQUIRED
http_access allow password

Пожалуйста, обратите внимание, что путь к вашему файлу паролей squid и к nsca_auth может отличаться в вашей системе. Тем не менее, вы можете изменить путь к вашему собственному файлу паролей на ваш собственный путь; nsca_auth имеет фиксированное месторасположение (используйте find или locate, чтобы получить корректный путь).
Имеются также другие значения аутентификации в squid. Дополнительные подробности смотрите на сайте прокси-сервера squid.
Чтобы предоставить доступ на основании пользовательских имен, у вас есть два варианта: вы можете непосредственно перечислить пользователей в тэге user вашего файла squidGuard.conf, или вы можете ввести имя файла (рекомендуется, если имеем дело с множеством имен) и использовать тэг userlist. В обоих случаях вы должны включить определения пользователя внутри определенного acl. Следующие два примера показывают, как использовать тэги user и userlist:

src department1 {
user maria josef susanna micheal george1
}

В этом примере пять пользователей группируются в источник  department1. Это источник используется, чтобы предоставить или запретить доступ определенным категориям (смотрите определение acl после следующего примера).
Вы можете использовать числа в именах пользователей. К сожалению, в текущее время есть баг squidGuard, выдающий ошибки при использовании имен пользователей, состоящих полностью из чисел. В этом случае используйте тэг userlist (см. след. пример), чтобы урегулировать пользовательский доступ:

src department1 {
userlist dep1users
}

В этом примере конфигурация squidGuard указывает на файл, называемый здесь dep1users, где могут быть найдены пользователи. Расположение файла со списком пользователей связано с путем, который вы определили для параметра dbhome.
Файл со списком пользователей - это обычный текстовый файл в следующем формате:

user1
user2
user3
user4
user5

и т.д.

Когда вы уже определили ваших пользователей, вы должны настроить, какой(ая) пользователь (группа) имеет доступ к какому назначению (destination). Это делается в части acl вашего конфигурационного файла squidGuard.conf:

acl {
department1 {
pass !porn !hacking !warez all
redirect http://localhost/cgi/blocked?clientaddr=%a&clientuser=%i&clientgroup=%s&url=%u
}
default {
pass white none
redirect http://localhost/cgi/blocked?clientaddr=%a&clientuser=%i&clientgroup=%s&url=%u
}
}

В этом примере пользователь department1 может иметь доступ ко всем веб-сайтам, кроме тех, которые перечислены в категориях porn, hacking и warez. Все остальным пользователям доступ разрешен только к тем ресурсам, которые перечислены в категории white (белый список). Конечно же, вы можете определить назначения до установки acl. :-)

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

Точно так же, как в примерах до этого, вы должны определить окружение src, где может быть найдена пользовательская информация. Вдобавок вы должны определить некоторые специфичные тэги LDAP: вы должны назвать верхний уровень дерева каталога LDAP и пароль для доступа к пользовательской информации (если только вы не используете анонимный режим (anonymous bind), который с точки зрения безопасности всегда не рекомендуется).
Существуют следующие LDAP-специфические тэги:

• ldapusersearch - Это ключевое слово входит в конфигурационный блок src и определяет URL LDAP для поиска неизвестного имени пользователя. Вы можете определить множество URL для LDAP в блоке источника src. Используйте '%s', чтобы определить имя пользователя в вашем URL для LDAP. Если поиск возвратит запись, пользователь считается "найденным", иначе проверяется следующий URL в блоке src. SquidGuard кэширует состояние "найден" для каждого поиска, даже когда имя пользователя не найдено. Кэш действителен в течение времени, которое задано параметром ldapcachetime (в сек.).
  

• ldapcachetime - это глобальное ключевое слово определяет число секунд для кэширования результатов поиска LDAP до соединения с сервером LDAP снова. Это ключевое слово глобально и должно находиться вне любых блоков src/dest/rule. Делая это значение достаточно низким, можно смоделировать сходную с реальностью группировку в LDAP без перезапуска squidguard. Рекомендованное значение: 300
  

• ldapbinddn - Глобальное ключевое слово, определяющее DN (Distinguished Name, уникальное имя), для того чтобы связаться с сервером LDAP.

• ldapbindpass - Пароль для связи с LDAP-сервером. Это глобальное ключевое слово.
  

• ldapprotover - Описывает версию протокола LDAP. Это глобальное ключевое слово. Используйте его, чтобы заставить squidGuard соединиться с LDAP-сервером, который имеет определенную версию протокола. Если вы не можете использовать определенную версию протокола, squidGuard перейдет в аварийный режим. Допустимые параметры: 2 или 3.
  

Примерная конфигурация:

ldapbinddn cn=root, dc=example, dc=com
ldapbindpass myultrasecretpassword

# ldap cache time in seconds
ldapcachetime 300

src my_users {
ldapusersearch ldap://ldap.example.com/cn=squidguardusers,ou=groups,dc=example,dc=com?memberUid?sub?(&(objectclass=posixGroup)(memberUid=%s))
}

Когда вы используете LDAP для аутентификации, убедитесь что параметры вашей строки ldapusersearch соответствуют пользовательским настройкам на вашем сервере LDAP. Если имена ваших пользователей не сохранены в "MemberUid", то "uid" вы должны соответственно адаптировать в вашей строке ldapusersearch . То же самое справедливо для значений, которые вы вводите для "objectclass". Вы, возможно, имеете что-то наподобие "Person" или "InetOrgPerson" вместо этого.
Если значение ldapusersearch не совпадает с вашими конфигурационными настройками, поиск завершится с ошибкой.