Установление подлинности с PPP..CHAP против PAP
С PPP, каждая система может требовать, чтобы peer опознал себя используя однин из двух опознавательных протоколов. Они - (PAP), и (CHAP). Когда связь установлена, каждый может запросить другой, чтобы опознать себя, независимо от того, является ли это caller или callee. Ниже я буду говорить о "клиенте " и " сервере " когда я захочу сделать различие между системой опознания и authenticator. PPP daemon может спрашивать peer отно подлинности, посылая однако другой LCP запрос конфигурации, опознавающий желаемый протокол.
PAP в основном работает в том же самом способ как нормальная процедура входа в систему. Клиент опознает себя, посылая имя пользователя и пароль ксерверу, который сравнивается с базой данных секретов. Этот метод легкоуязвим к eavesdroppers, который может попытаться получить пароль, слушая последовательную линию, и к повторению испытания и решения ошибки.
CHAP не имеет этих недостатков. С CHAP, authenticator (то есть сервер) посылает беспорядочно сгенерированную " challenge'' строку к клиенту, наряду с hostname. Клиент использует hostname для того, чтобы искать соответствующий шифр, объединяя это с challenge, и шифруя строку, используя однонаправленную hashing function. Результат будет возвращен на сервер наряду с hostname клиента. Сервер теперь выполняет то же самое вычисление, и подтверждает клиента.
Другая особенность CHAP - то, что он не требуется опознания клиента для опознания самого себя при запуске, но посылает challenges в определенные промежутки времени, чтобы удостовериться не был клиент заменен "злоумяшлепником ", например, только переключая телефонные линии.
Pppd хранит секретные ключи для CHAP и PAP в двух отдельных файлах, вназываемых /etc/ppp/chap-secrets и pap-secrets соответственно. Входом отдаленного хоста в один или другой файл, Вы имеете хороший контроль над CHAP или PAP предназначенный для этого, чтобы опознать нас с нашим peer, и наоборот.
По умолчанию, pppd не требует установления подлинности от remote, но соглашается опознавать себя когда запрошено remote. Так как CHAP намного более сильна чем PAP, pppd пробует использовать вышеупомянутый всякий раз, когда это возможно. Если peer этого не поддерживает, или если pppd не может найти CHAP шифр для remote системы в файле шифров chap, он возвращается к PAP. Если он имеет PAP шифр для peer также, то он откажется опознавать в целом, и как следствие, связь закроется.
Это поведение может быть изменено отдельными способами. Например, когда дается auth ключевое слово, pppd требует, чтобы peer опознал сам себя. Pppd согласится использовать или CHAP или PAP для этого, как только это будет имеет шифр для peer в CHAP или в базе данных PAP соответственно. Имеются другие опции, чтобы включить или выключить частный опознавательный протокол, но я не буду описывать их здесь. Пожалуйста обратитесь к pppd (8) для деталей.
Если все системы, с которыми Вы говорите PPP, соглашаются опознавать самих себя с Вами, Вы должны поместить опцию auth в глобальный файл /etc/ppp/options и определить пароли для каждой системы в файле шифров chap. Если система не поддерживает CHAP, добавьте запись к файлу pap шифров. Таким образом, Вы можете удостовериться в том, что никакая неопознанная система не соединяется с Вашим хостом.
Следующие два раздела обсуждают два PPP файла шифров, pap- secrets и chap-secrets. Они размещзны "в /etc/ppp и содержат тройки клиентуры, серверов и паролей, необязательно сопровождаемых списком из адресов IP. Интерпретация клиента и областей сервера отлична для CHAP или PAP, и также зависит от того, опознаем ли мы себя самостоятельно с peer, или потребуем опознать сервер непосредственно с нами.
