Not possible to disable password-saving in NetworkManager

[netdata]

I liked the Maverick release in regards to the VPN setup. When no password was filledin it asked for a password each time I try to login. Handy because I need to enter a unique ID each time via a VASCO key.

Since Oneiric I need to clear the password each time I want to connect to the VPN so I can enter the correct one. Although there is nowhere a checkbox to be seen that sets save password (like in the previous version) it does it anyhow. Is this a bug (or was the previous way to do it a bug)?

Is there a setting I missed? It seems something in the network manager.

[nathanvda (xh-nathan)]

I am having the same problem here. We are using a device to generate an OTP, so my password is unique everytime I log on, so automatically saving the password is actually a hassle for me. I can understand the default would be to automatically save the password, but isn't there some option to turn that off?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[FiX (fix-kowalski)]

I am using PPTP + OATH for the exact same purpose. OATH is a 2-factors authentication device that generates a unique password. Now that NM saves the password, it is no longer usable for 2-factor authentication...

[Matt Fischer (mfisch)]

This is not part of gnome-nettools, I believe it belongs to network manager.

[Zoltán Nagy (nagyzo)]

Yes, a checkbox/selector should be added to nm-applet (for PPTP) that is mapped to "password-flags".

Until the nm-applet GUI is not fixed, here is the workaround to disable password saving.

Setup the flag "password-flags=2" under [vpn] section in the related VPN config file, located here in Ubuntu:

  /etc/NetworkManager/system-connections/<name of your vpn connection>

[vpn]
password-flags=2

[netdata (bj7u6139z-info-jjcftv6wl)]

Great !

I can confirm the work-arround works !

[nathanvda (xh-nathan)]

Awesome, indeed, I confirm the fix works for me too.

[FiX (fix-kowalski)]

I would not call this a fix, but indeed a working work-around. Is there any associated change-request reported upstream by anyone?