Red Hat Bugzilla – Bug 65297
RFE: defining a ppp connection should not require a password
Last modified: 2007-11-30 17:10:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
Description of problem:
Defining a PPP interface currently *requires* a username and password. I
frequently set up laptops that will be used by multiple people (e.g. members of
a research group) and the same dialup connection will be used by all of them,
but the login/password combo should be different -- I don't want Joe Blow
authenticating as John Doe. Username and password should be optional fields
during setup, and rp3 should prompt for them on execution if they aren't defined
in the config file. Moreover, the username/password pairs are stored plaintext,
so anyone with physical access to the laptop can recover them, even if the file
permissions are restrictive.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
2.define a new ppp connection
3.click "next" without entering a username and/or password.
Actual Results: dialog refused to proceed
Expected Results: empty username and/or password should have been saved, and
rp3 should prompt for values (without storing them to disk) when called to
I second this RFE, because sometimes having a fixed PPP password is not enough...
In my company, people have the opportunity to do teleworking, i.e. from
their computer at home. The way this works is that you get an ADSL connection
with two different logins, one to the ISP's network, and one to the company's
network. The ISP's network has a fixed password, but the company's network
uses a password that is given by a so-called 'hard token', for security
This token looks a bit like a small calculator. When the employee wants to
do teleworking, he stops the connection to the ISP and starts the connection
to the company's network. He types a four-digit code into the token, and the
token returns an 8-digit password, which needs to be used as PPP password.
This is currently not supported by redhat-config-network, which requires a
fixed password. However, I did get it working in the way described below.
I propose that redhat-config-network is enhanced to allow dynamic passwords,
without having the user to perform the explicit steps given below.
How I got it working (on Red Hat Linux 9):
- Install the passprompt plugin of the ppp daemon. This is not installed
by Red Hat Linux, but it is included in the sources of pppd (file
pppd/plugins/passprompt.c and scripts in the contrib directory), so I
installed it myself from the sources [Note 1]
- Add a new interface via redhat-config-network, with a dummy password
(suppose this is the ppp1 interface)
- Remove the entries for the new login from /etc/ppp/papsecrets and
/etc/ppp/chapsecrets (because pppd should *not* get the dummy password)
- Add to ifcfg-ppp1 the following line:
PPPD_EXTRA='plugin passprompt.so promptprog /usr/bin/pppgetpass'
This is used by the adsl-connect script of rp-pppoe.
- When a password is now needed for ppp1, the plugin passprompt.so will ask
the password from the user, using the program pppgetpass. Depending on
whether the DISPLAY variable is set in the environment, pppgetpass will
use a small GTK window, or will just pose the question on the console.
1. The passprompt plugin has a bug in pppd: it removes the last character from
the password. I have patched the passprompt.c file in my system to correct
this, but I noticed that in the current beta of pppd 2.4.2 the bug is
2. The DISPLAY variable should be set in the environment of pppd. If you
start the connection via redhat-control-network from the GNOME menu,
apparently this variable is not set, and pppgetpass switches temporarily
back to the console to ask the password (you don't get this if you perform
adsl-start from a terminal that has the DISPLAY properly set).
I haven't searched very hard yet how to fix this, since it's only a
nuisance. But of course if redhat-config-network would support dynamic
passwords, this should not happen...