I hope someone can help me because I have spent a week on this and still I can't make it to work.
I have a CentOS 5.5 server and I am trying to set it up so that upon login the gnome default keyring is unlocked. I don't have a desktop as users will login using ssh only.
I have search the forum and google it, and I did find some help. All the articles though said to change /etc/pam.d/gdm (which I think is for the Gnome Desktop Manager). I did it anyway but no joy. I tried changin /etc/pam.d/login, and no joy. I'm becoming a bit desperate.
The changes I have done are to add
auth optional pam_keyring.so
(sometimes with try_first_pass) and
session optional pam_keyring.so auto_start
(sometimes without auto_start)
All the time the gnome-keyring-daemon is not started. But even if I start it at login, with a new /etc/prodile.d/gnome-keyring-daemon.sh script which runs export `/usr/bin/gnome-keyring-daemon`, the keyring is not unlocked at login.
Just to let you know, I use the keyring to store passwords for a Subversion repository. The first time, after logging in, I use Subversion I am asked for the password to unlock the keyring. Then everything goes fine, i.e. I'm not ask for the Subversion password.
After I sorted this out I need to set the server so that the keyring password is changed automatically when the user changes his login password (I tried alread, changing /etc/pam.d/passwd similarly as I've done above but it's not working)
So, please can anyone help me?
Thanks Giulio
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Giulio Troccoli wrote:
I hope someone can help me because I have spent a week on this and still I can't make it to work.
I have a CentOS 5.5 server and I am trying to set it up so that upon login the gnome default keyring is unlocked. I don't have a desktop as users will login using ssh only.
I have a similar situation. I'm not quite familiar enough with linux to know if my experience will help you. Anyway ...
I boot my laptop home computer (1 user) into runlevel 5 with *auto-login*. It has wifi built-in, and I wanted to set it up to auto-connect, _and_ not have to enter the keyring password.
I tried making the keyring's password the same as the user's - didn't work. To test the process, I turned off auto-login - it worked!
My semi-newbie skills led me to the conclusion that, if gnome does not have to ask for the password (auto-login mode), then the keyring manager never sees it (and asks for it anyway). Conversely, if gnome has to ask for the password (standard log-in mode), the keyring manager sees it, and the keyring is unlocked.
To help me learn a bit more, inform me how much this applies to your situation. You're working on a server; do you use auto-login for your own account?
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
-----Original Message-----
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Michael Klinosky Sent: 14 July 2010 00:15 To: CentOS mailing list Subject: Re: [CentOS] Unloking gnome keyring on login
Giulio Troccoli wrote:
I hope someone can help me because I have spent a week on this and still I can't make it to work.
I have a CentOS 5.5 server and I am trying to set it up so
that upon
login the gnome default keyring is unlocked. I don't have a
desktop as
users will login using ssh only.
I have a similar situation. I'm not quite familiar enough with linux to know if my experience will help you. Anyway ...
I boot my laptop home computer (1 user) into runlevel 5 with *auto-login*. It has wifi built-in, and I wanted to set it up to auto-connect, _and_ not have to enter the keyring password.
Thanks for trying Michael, but as I said I don't use a desktop, i.e. the server boots up at level 3. All users use a terminal to ssh into the server, so auto-login is not an option.
Giulio
Just to let you know, I use the keyring to store passwords for a Subversion repository. The first time, after logging in, I use Subversion I am asked for the password to unlock the keyring. Then everything goes fine, i.e. I'm not ask for the Subversion password.
Which version of Subversion are you using?
Just a thought: don't you think you should rather go for a Subversion specific mechanism to store the passwords / access safely the repositories?
I can imagine that you are worried about the famous limitation that SVN passwords are stored in plaintext on Linux: http://help.collab.net/index.jsp?topic=/faq/cachepassword.html http://www.linuxforu.com/previews/subversion-16-security-improvements-illust...
But maybe, if you control the SVN server config as well, you could setup a certificate based auth in Apache (restricted to your clients IPs) without requiring to use the actual password: your Linux client setup would then be as safe as your Linux auth (since the certificates would be protected in the .subversion of your users)
Another approach could be to use an svn+ssh:// access to your repository for your server-side Linux users. The problem is that it doesn't work well with parallel access. But if this is just to start a build from time to time that may be enough... (I hope your developers are not working on their code on a server from the command line :)
I was just trying to think on another approach, in case this is only for Subversion that you have to go through this pain. It feels kind of wrong to use gnome-keyring on the server (I use it with pam_keyring on my CentOS workstations, but you already tried that).
Anyhow, I'm really interested in your effort, because I will have to set up something similar soon.
Just to let you know, I use the keyring to store passwords
for a Subversion repository. The first time, after logging in, I use Subversion I am asked for the password to unlock the keyring. Then everything goes fine, i.e. I'm not ask for the Subversion password.
Which version of Subversion are you using?
1.6.9
Just a thought: don't you think you should rather go for a Subversion specific mechanism to store the passwords / access safely the repositories?
I can imagine that you are worried about the famous limitation that SVN passwords are stored in plaintext on Linux: http://help.collab.net/index.jsp?topic=/faq/cachepassword.html http://www.linuxforu.com/previews/subversion-16-security-impro vements-illustrated/
Subversion is already set up correctly to use the keyring mechanism to store the password. It works. But, the first time I'm asked for the password to unlock the keyring. This is what I am trying to avoid. I don't think this has anything to do with Subversion.
But maybe, if you control the SVN server config as well, you could setup a certificate based auth in Apache (restricted to your clients IPs) without requiring to use the actual password: your Linux client setup would then be as safe as your Linux auth (since the certificates would be protected in the .subversion of your users)
I'm not sure I understood you here. This way any user coming from one of those IP will have access to the repository? How would I know who it is though?
Another approach could be to use an svn+ssh:// access to your repository for your server-side Linux users. The problem is that it doesn't work well with parallel access. But if this is just to start a build from time to time that may be enough... (I hope your developers are not working on their code on a server from the command line :)
We did start with svn:// access, about 5 years ago when we started using Subversion, but we abandoned it in favour of http://. Honestly, I don't remember what was the problem.
What do you mean by "I hope your developers are not working on their code on a server from the command line" ?
I was just trying to think on another approach, in case this is only for Subversion that you have to go through this pain. It feels kind of wrong to use gnome-keyring on the server (I use it with pam_keyring on my CentOS workstations, but you already tried that).
Most of the work is done on PC, so gnome-keyring is not needed. But some work is done on the server, in personal working copies, and therefore I need a mechanism to store passwords. Because these are company passwords, I used LDAPS to authenticate against the company AD, they need to be encrypted.
Giulio
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
Sorry, if I was not clear: I was just throwing ideas because I will have soon to face a similar need. I just wanted to explore if you could avoid using the gnome-keyring at all. I was not pretending to give you a direct solution for your pb.
Subversion is already set up correctly to use the keyring mechanism to store the password. It works. But, the first time I'm asked for the password to unlock the keyring. This is what I am trying to avoid. I don't think this has anything to do with Subversion.
Yes, but you have to use gnome-keyring in the first place because of this SVN password caching issue.
I'm not sure I understood you here. This way any user coming from one of those IP will have access to the repository? How would I know who it is though?
You would have to issue certificates for the client. Definitely not a good option for you if you have many users. Could make sense if these are only "special" users such as build processes who need to access the SVN repo.
We did start with svn:// access, about 5 years ago when we started using Subversion, but we abandoned it in favour of http://. Honestly, I don't remember what was the problem.
svn+ssh:// is not (exactly) the same as svn:// - svn:// access a svnserve daemon via the network - svn+ssh:// is actually more like file:// (but safer), it starts remotely an svnserve for each call and only for the duration of this call, reuse the OS credential and access the repository on the filesystem directly => it can be combined with http:// and access the same repository, but again would only work reasonably if there are not too many such accesses => if your OS users are also managed by LDAP this could offer you a consistent approach: in the end you would have the same user names in subversion whether you access it one way or the other
What do you mean by "I hope your developers are not working on their code on a server from the command line" ?
I was just joking. Usually people develop from their workstation. Although I have already seen some development being done directly with vi on headless servers...
Most of the work is done on PC, so gnome-keyring is not needed. But some work is done on the server, in personal working copies, and therefore I need a mechanism to store passwords. Because these are company passwords, I used LDAPS to authenticate against the company AD, they need to be encrypted.
If you PC are running Linux, then you have the same problem (unencrypted password). But I guess your users are on Windows PCs.
No-one else has anything to say about this problem?
Linedata Limited Registered Office: 85 Gracechurch St., London, EC3V 0AA Registered in England and Wales No 3475006 VAT Reg No 710 3140 03
-----Original Message-----
From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Mathieu Baudier Sent: 14 July 2010 11:01 To: CentOS mailing list Subject: Re: [CentOS] Unloking gnome keyring on login
Sorry, if I was not clear: I was just throwing ideas because I will have soon to face a similar need. I just wanted to explore if you could avoid using the gnome-keyring at all. I was not pretending to give you a direct solution for your pb.
Subversion is already set up correctly to use the keyring
mechanism to store the password. It works. But, the first time I'm asked for the password to unlock the keyring. This is what I am trying to avoid. I don't think this has anything to do with Subversion.
Yes, but you have to use gnome-keyring in the first place because of this SVN password caching issue.
I'm not sure I understood you here. This way any user
coming from one of those IP will have access to the repository? How would I know who it is though?
You would have to issue certificates for the client. Definitely not a good option for you if you have many users. Could make sense if these are only "special" users such as build processes who need to access the SVN repo.
We did start with svn:// access, about 5 years ago when we
started using Subversion, but we abandoned it in favour of http://. Honestly, I don't remember what was the problem.
svn+ssh:// is not (exactly) the same as svn://
- svn:// access a svnserve daemon via the network
- svn+ssh:// is actually more like file:// (but safer), it
starts remotely an svnserve for each call and only for the duration of this call, reuse the OS credential and access the repository on the filesystem directly => it can be combined with http:// and access the same repository, but again would only work reasonably if there are not too many such accesses => if your OS users are also managed by LDAP this could offer you a consistent approach: in the end you would have the same user names in subversion whether you access it one way or the other
What do you mean by "I hope your developers are not working
on their code on a server from the command line" ?
I was just joking. Usually people develop from their workstation. Although I have already seen some development being done directly with vi on headless servers...
Most of the work is done on PC, so gnome-keyring is not
needed. But some work is done on the server, in personal working copies, and therefore I need a mechanism to store passwords. Because these are company passwords, I used LDAPS to authenticate against the company AD, they need to be encrypted.
If you PC are running Linux, then you have the same problem (unencrypted password). But I guess your users are on Windows PCs. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Giulio Troccoli -
Mathieu Baudier -
Michael Klinosky