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): How reproducible: Always Steps to Reproduce: 1.run redhat-config-network 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 initialize connection. Additional info:
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 reasons. 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. [Note 2] Notes: 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 fixed. 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...
sounds nice...
https://hosted.fedoraproject.org/projects/system-config-network/ticket/1