Bug#519314: Regression: no longer adds my SSH keys to the agent
Package: libpam-ssh Followup-For: Bug #519314 I very much like the idea that pam-ssh has added a mechanism to allow users to configure additional SSH keys to unlock on login without requiring system-wide configuration via the keyfiles option. The login-keys.d directory seems like a sensible way to do this. However, this configurability should not come at the expense of working out-of-the-box without per-user configuration. Unlike previous versions, this new version of libpam-ssh no longer adds my keys to the agent by default. This represents a regression from previous versions. I read the debian-devel thread in question, and the only complaint I saw about using id_* by default related to taking advantage of a key with a weak or well-known passphrase to log in as the user. This only seems like a problem when configuring pam-ssh as a login mechanism, rather than only a mechanism to run an ssh-agent and unlock keys as many people do. Thus, I have a proposal which I think will address these concerns while still working out-of-the-box: - Always attempt to unlock all keys matching id_* and add them to the ssh-agent. Alternatively, at least unlock keys matching id_rsa, id_dsa, and identity, as SSH does and the previous version of pam-ssh did. Since you can only unlock keys this way if you know their passphrase, this shouldn't represent a security problem. - For authentication purposes, only treat keys linked from login-keys.d as sufficient for authentication. This ensures that people don't inadvertently allow authentication via an unexpected key. Thus, if I have no login-keys.d directory, pam-ssh will not allow me to use my SSH keys to log in, but it will still unlock any keys that my normal password unlocks and add them to ssh-agent. Now, this still potentially represents a regression for people who use pam-ssh for authentication. However, it seems more reasonable to allow a regression there to prevent a potential security problem. I don't use pam-ssh for authentication, so I can't speak for the people who do; the behavior I described above will at least fix the regression for people who use pam-ssh just to unlock their keys. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519314: Regression: no longer adds my SSH keys to the agent
I am truly sorry that you are being bothered by the changes in the new Debian version of libpam-ssh. The story is that the new version of libpam-ssh will look for keys in $HOME/.ssh/login-keys.d/, and only there. I implemented that functionality after a discussion on the debian-devel mailing list [1] and an announcement on pam mailing list (with no response). Since then, the new version of libpam-ssh has been available in experimental, and because I have had no complaints about it so far, I have uploaded it to unstable. Personally I think the new setup is better because it relieves the administrator from doing any special setup for users, while at the same time enabling individual users to use as many keys as they like (cf [3]). But maybe libpam-ssh should look for the same set as key as ssh does in addition to $HOME/.ssh/login-keys.d/ ? [1] http://lists.debian.org/debian-devel/2008/12/msg00193.html [2] https://www.redhat.com/archives/pam-list/2008-December/msg4.html [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477272 Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#519314: Regression: no longer adds my SSH keys to the agent
Package: libpam-ssh Version: 1.92-5 Severity: normal After upgrading from libpam-ssh 1.91.0-9.3 to libpam-ssh 1.92-5, libpam-ssh no longer uses my password to add my SSH keys to the ssh-agent it starts. The changelog for libpam-ssh suggested that it would now unlock any key matching id_*, which my keys do. Another entry in the changelog suggested that libpam-ssh now looks for keys in $HOME/.ssh/login-keys.d/ , but I certainly hope it doesn't *require* keys to appear in that directory. That would represent a regression from previous versions, which found my keys without that extra configuration. - Josh Triplett -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.28-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libpam-ssh depends on: ii libc6 2.9-4 GNU C Library: Shared libraries ii libpam0g 1.0.1-7Pluggable Authentication Modules l ii libssl0.9.8 0.9.8g-15 SSL shared libraries Versions of packages libpam-ssh recommends: ii openssh-client [ssh-client] 1:5.1p1-5 secure shell client, an rlogin/rsh libpam-ssh suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
