[ Что нового ? | Заметки | Статьи | Ссылки | Настройка pppd ]     [ win | koi ]
24.08.1999, © Igor Sysoev, igor@nitek.ru

 

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

 

Поскольку при аутентификации через CHAP мы должны высылать удалённой стороне случайный ключ и имя нашей системы, это имя необходимо задать с помощью параметра name, например, в файле /etc/ppp/options:

modem
crtscts
asyncmap 0
name fast

Если мы не укажем имя нашей системы, pppd будет использовать в этом качестве полное доменное имя компьютера, на котором его запустили, в нашем случае, dial.fast.ru. Иногда в рекомендациях по настройке pppd зачем-то используют параметр domain. Я не знаю, какая цель при этом преследуется, но этот параметр влияет только на имя нашей системы. Если мы укажем параметр domain fast.ru, то имя нашей системы станет dial.fast.ru.fast.ru. Не знаю, как Вам, но мне это совершенно не нужно. Что касается PAP, то для него имя нашей системы не обязательно, но не помешает.

В принципе, для клиентов, использующих аутентификацию PAP или CHAP может вообще не быть записи в /etc/master.passwd, поскольку имена и пароли для аутентификации находятся в файлах /etc/ppp/pap-secrets и /etc/ppp/chap-secrets (для краткости мы будем называть их файлы secrets) в виде строк:

max		fast		abcdefg		*

Формат этой строки такой - имя удалённой системы "max", имя нашей системы "fast", пароль удалённой стороны "abcdefg" и разрешенные для удалённой стороны IP-адреса "*" (символ "*" означает любые). secrets-файл на удалённой стороне должен содержать похожую строку:

max		fast		abcdefg

но там поля имеют другой смысл - имя его системы - "max", имя нашей системы - "fast" и пароль - "abcdefg".

В одном и том же файле могут хранится имена и пароли как для аутентификации удалённых систем, так и для аутентификации себя. Первые визуально отличаются наличем поля IP-адреса. Кроме того, имя нашей системы при аутентификации удалённых систем можно заменить символом "*". Таким образом, наш файл secrets будет выглядеть так:

igor		cool		1234567
max		*		abcdefg		*

Первая строка - это наше имя и пароль для аутентификации у нашего провайдера Cool Connection, а вторая - это строка для аутентификации нашего дайлап-клиента "max".

В файле /etc/ppp/pap-secrets пароль клиента может хранится не открытым текстом, а в виде результата функции crypt, например, вот так:

 
max		*		$1$1q2w3e4r$UptrhXMwGUeq2z68qDcXi/	*

При PAP аутентификации pppd сначала пытается сравнить присланный пароль с имеющимся и, если они не совпадают, pppd пропускает его через crypt и пытается сравнить снова.

Если pppd указать параметр login, то при PAP аутентификации он будет проверять в /etc/master.passwd пароль пользователя, имя которого совпадает с именем удалённой системы. Кроме того, pppd проверит, что бы это имя не было в файле /etc/ppp/ppp.deny, а шелл этого пользователя присутствовал в файле /etc/ppp/ppp.shells. Помимо этого, проверяется срок действия аккаунта пользователя.

Файлы /etc/ppp/ppp.deny и /etc/ppp/ppp.deny и срок действия аккаунта проверяет только pppd, входящий в комплект FreeBSD. О других отличиях читайте в статьте Сравнение версии pppd, входящей в дистрибутив FreeBSD, c обычной версией

Если все проверки пройдут удачно, pppd запишет время работы этого пользователя в файле /var/log/wtmp. При использовании параметра login пароль клиента может вообще не храниться в /etc/ppp/pap-secrets:

max		*		""		*

Надо заметить, что хранить пароль в шифрованном виде или в виде "" можно только при аутентификации PAP. Используя CHAP, мы вынуждены хранить пароль открытым текстом.

Теперь перейдем к полю адреса. Как мы уже говорили, символ "*" в четвёртом поле файла secrets разрешает удалённой стороне использовать любой адрес, но мы так же можем разрешить использование только определеных адресов, указав их через пробел:

 
max		*		abcdefg		192.168.1.200 192.168.1.201

То есть, в нашем случае, "max", пользуясь аутентификацией через PAP или CHAP, сможет заходить только на линии ttyd1 и ttyd2.

Если число запрещённых адресов меньше, чем разрешённых, то удобнее воспользоваться символом "!":

 
max		*		abcdefg		* !192.168.1.202

то есть, разрешить все и запретить 192.168.1.202. В нашем случае, это аналогично предыдущему варианту.

Любые диапазоны разрешать нельзя, но можно разрешать адреса, входящие в указанную подсеть:

 
max		*		abcdefg		192.168.1.200/30

то есть, разрешить все адреса с 192.168.1.200 по 192.168.1.203.

Указав в поле адреса на первом месте символ "-", мы запрещаем использовать любые адреса, что выливается в невозможность аутентификации через PAP или CHAP для данного клиента:

max		*		abcdefg		-

Того же эффекта можно достичь, вообще убрав поле адреса.

Наконец, с помощью этого поля можно назначить адрес удалённой стороне:

 
max		*		abcdefg		:192.168.1.210

или оба адреса для данного соединения:

 
max		*		abcdefg		192.168.1.2:192.168.1.210

Это назначение происходит уже после того, как pppd назначил адреса в описанном нами порядке и является завершающей стадией в этой эпопее. Вместо IP-адресов можно использовать доменные имена.

Назначать адреса в secrets-файлах может только pppd, входящий в комплект FreeBSD. О других отличиях читайте в статье Сравнение версии pppd, входящей в дистрибутив FreeBSD, c обычной версией

Может ли pppd использовать для аутентификации одних клиентов PAP, а для других - CHAP ? В общем случае - нет. Дело в том, что о способе аутентификации pppd договаривается с удалённой стороной ещё до того, как эта удалённая сторона сообщит своё имя. В результате может возникнуть следующая ситуация. Перед тем, как определить способ аутентификации, pppd заглядывает в файл /etc/ppp/chap-secrets и, если он находит там хотя бы одну строку, у которой второе поле равно "*" или совпадает с именем нашей локальной системы, то он предлагает удалённой системе аутентификацию через CHAP. Если удалённая сторона согласится и затем с самыми хорошими намерениями передаст нам своё имя, а этого имени в файле /etc/ppp/chap-secrets не окажется, то аутентификация не удастся. Если на удалённой стороне пользуются pppd и точно знают, что аутентификация через CHAP им не светит, они могут указать ему параметр refuse-chap и удалённый pppd ответит отказом, после чего аутентификация будет проводиться через PAP. Если же на удалённой стороне используется Windows, то дело тухляк. В Windows можно отказаться от PAP, но никак не от CHAP.

Поэтому, если мы решили использовать CHAP, то всех клиентов под Windows придется занести в файл /etc/ppp/chap-secrets. Я бы рекомендовал использовать PAP для всех клиентов, потому что в этом случае, во-первых, пароль можно хранить в зашифрованном виде или даже в /etc/master.passwd, а во-вторых, параметр login записывает время работы клиента. Что касается того, что пароль передаётся в открытом виде по каналам связи, то для телефонных линий, на мой взгляд, это не критично. Поэтому в наш файл /usr/sbin/pppd.sh можно добавить такие параметры:

#!/bin/sh

/usr/sbin/pppd auth login require-pap refuse-chap

Мы запрещаем CHAP, требуем PAP, используем для аутентификации /etc/master.passwd, и, кроме того, записываем время работы в файл /var/log/wtmp.

counter