Установление подлинности с 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,   или  потребуем опознать сервер непосредственно с нами.