Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 165919 - Review Request: pam_ssh Pluggable Authentication Module for ssh
Summary: Review Request: pam_ssh Pluggable Authentication Module for ssh
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2005-08-14 13:25 UTC by Patrice Dumas
Modified: 2011-06-07 15:09 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-09-01 09:53:26 UTC
Type: ---
j: fedora-cvs+

Attachments (Terms of Use)

Description Patrice Dumas 2005-08-14 13:25:08 UTC
SRPM Name or Url:

This PAM module provides single sign-on behavior for UNIX using SSH. Users
are authenticated by decrypting their SSH private keys with the password
provided (probably to XDM). In the PAM session phase, an ssh-agent process is
started and keys are added.

Comment 1 Tom "spot" Callaway 2005-08-14 19:19:47 UTC


- rpmlint returns nothing
- naming is fine
- meets PackagingGuidelines
- license ok (BSD), matches source
- spec file in Am. English, legible
- package builds ok on x86 (FC4)
- all BuildRequires ok
- no locales
- no libs (pam so is ok)
- not relocatable
- doesn't make new directories
- %clean section ok
- no duplicate %files
- macro use is consistent
- code not content
- no need for -docs, -devel
- .la files deleted


- COPYING needs to be included in %doc
- URL is wrong in Source: ... should be:{name}-%{version}.tar.bz2

Very Bad:

- md5sums do NOT match upstream
[spot@swoop ~]$ md5sum rpmbuild/SOURCES/pam_ssh-1.91.tar.bz2
4f4e796b28883387261ac662c972b562  rpmbuild/SOURCES/pam_ssh-1.91.tar.bz2
[spot@swoop ~]$ md5sum pam_ssh-1.91.tar.bz2
57a3aa476394efa219a8a99f527d4e4b  pam_ssh-1.91.tar.bz2

Please fix the Needswork and Very Bad items and I'll re-review.

Comment 2 Patrice Dumas 2005-08-14 22:43:37 UTC
Hopefully this should be fixed in:

Comment 3 Dmitry Butskoy 2005-08-15 10:29:34 UTC
  Oh, you have outsripped me! I wanted to add this package to FC Extra too... :-)

  We successfully use pam_ssh already more than year. There are two patches
(made by me) which are necessary. A first patch makes the "session" part
stand-alone (i.e., when "auth" part was not used). This is very useful in
combination with pam_console login/gdm authentication. A second patch moves
state files from ~/.ssh to system /var/run . This provides properly cleanup
after system crash.

  Also, I change the spec file. Openssl dependencies are added, words "using
SSH' are changed to "using SSH keys", etc.

  Spec file:

  Patrice, Tom,

  Please, check my variant (and my patches). We use this package logn enough at
our system, these patches are caused by real life...

Comment 4 Tom "spot" Callaway 2005-08-15 12:13:52 UTC

Dmitry's patches look good... you should merge them into your spec.

The md5sums match upstream now, and all the blockers are resolved. 

Comment 5 Dmitry Butskoy 2005-08-15 12:49:45 UTC

  Did you check my patches? Not spec-file changes only? (Noone downloaded my
srpm yet).


  Probably it will be better if you use my spec-file, just rewrite changelog
section, having mentioned me once because of two patches added.

Comment 6 Tom "spot" Callaway 2005-08-15 12:55:17 UTC

Your spec file needs some cleanups, whereas Patrice's spec file is OK at this
point. It should be easy enough to merge your patches into Patrice's spec.

Your patches look ok to me, but I'm relying on the fact that you've used this
package. :)

Comment 7 Patrice Dumas 2005-08-15 13:02:50 UTC

I update my spec with your patches and changes, test it and repost it. 

Comment 8 Dmitry Butskoy 2005-08-15 13:09:08 UTC
Where can I download it from?? :-)

Comment 9 Patrice Dumas 2005-08-15 13:24:41 UTC
Here it is:

Comment 10 Dmitry Butskoy 2005-08-15 13:50:07 UTC
  The version-release in the last changelog entry is 0:1.91-1, srpms has 1.91-3
  Is it actually gcc-c++ needed??

  Please, merge in summary and description too. IMHO my phrases describe this
pachage more precisely. (I mean "SSH keys" instead of just "SSH", and the fact
that additional session calls just sets environment without extra ssh-agent

Comment 11 Patrice Dumas 2005-08-15 14:23:24 UTC
New version at

I removed gcc-c++ it is an old leftover when I used mach and there was a libtool
bug. Now gcc-c++ is in the build root and hpefully the libtool bug has been solved.

I merged your description but I changed it a bit. Tell me if you don't like it:

This PAM module provides single sign-on behavior for UNIX using SSH keys.
Users are authenticated by decrypting their SSH private keys with the
password provided. In the first PAM login session phase, an ssh-agent
process is started and keys are added. The same agent is used for the
following PAM session.

Comment 12 Patrice Dumas 2005-08-15 14:40:37 UTC
Regarding the patch that allows the information to be in /var/run/pam_ssh I find
it good, except that (at least for me) the files have permissions such that the
user cannot read the agent informations back from that file. I think this is

-r--------  2 root dumas 134 aoû 15 15:09 dumas
-r--------  2 root dumas 134 aoû 15 15:09 dumas-:0

A possible solution could be to have the user own that file. In that case thee
user may read it but still cannot delete it. If the user should be able to
delete the file the a directory should be created in /var/run/pam_ssh for the
user and the files placed in that directory.

Is there a specific reason why you made this file unreadable and unremovable by
the user?

Comment 13 Dmitry Butskoy 2005-08-15 14:43:01 UTC
  Change also "SSH" to "SSH keys" in the summary, for the same reason.

  Your phrase about session phase is better than mine. But for more transparency
we should tell somehow that session phase sets an appropriate environment, which
locates ssh-agent. Otherwise some people will not understand, how this module works.

Comment 14 Dmitry Butskoy 2005-08-15 14:49:39 UTC
  About /var/run/pam_ssh permissions:

  These files are "readable" due to "openpam_restore_cred()" call before we open
(or create) them. I.e., actually we open them under root.
> Is there a specific reason why you made this file unreadable and unremovable by
the user?
Is there any reason we should made this files readable/removable for the user?

  (For example, all under /var/run/console/ is owned by root).

Comment 15 Dmitry Butskoy 2005-08-15 15:00:27 UTC
  The idea to create a directory under /var/run/pam_ssh/ was considered by me.
Unfortunately, system initscripts only clear things like "/var/run/<dir>/*" . To
clear "/var/run/pam_ssh/<dir>/*" some changes to /etc/init.d/rc.sysinit should
be done. To avoid it I has applied a way without subdirectory creation.
  IMHO, it is even better for security that the user cannot read/remove this
files. And pam_console case is an existing precedent which votes for it.

Comment 16 Patrice Dumas 2005-08-15 15:09:54 UTC
Here is another try. I added a phrase about the environment variables set by
pam_ssh but I wasn't very precise. I don't think technical details should appear
in the rpm description. They belong to the package documentation. A patch to the
man pages or the README should be a better for precisions about the environment
variables in my opinion. 

I also didn't change the summary because I think it is an unneeded precision
that restrict the pam_ssh scope. Otherwise said pam_ssh is usefull with ssh, not
only for ssh keys. I myself don't use pam_ssh for the single sign on
capabilities but because it starts the agent.

Comment 17 Dmitry Butskoy 2005-08-15 15:35:04 UTC
  Now agree with description :-)

  But I not agree that this is a technical details. It is important to specify
that this module works with keys, and things related to keys (ssh-agent). This
module does not start any ssh remote terminals, does not operate as an
authentication proxy, does not use ssh as "check if a command invokation is
success", etc. etc. If we say just "SSH", the user can misunderstand it. If we
say "SSH keys", it is more precisely.
  "SSH keys" mean that pam_ssh works with ssh keys, starts the sshkey-related
program "ssh-agent" (if needed), and nothing also.

Comment 18 Patrice Dumas 2005-08-15 16:01:42 UTC
Regarding the permissions on the /var/run/pam_ssh/ files there is a use for a
file readable by the user. Indeed if the user log through a mean without the
pam_ssh module used he still can use the agent by sourcing the file.

Now as to have a file the user may modify the aim would be to let the user
manage the pam_ssh related files. Also this shouldn't have security implications
(related with ssh) as it is how things are currently done; the user may
manipulate the environment anyway.

In my opinion the difference is that now the files are in /var/run/pam_ssh and
not in the user home directory. So having files or dirs owned by the users may
create issues because of that. For example if there is a directory owned by a
user as I described above the user may fill the var file system. And if the user
 is the file owner he should be able to change the permissions, thus may for
example permit other users to read or modify it or change the perms such that
the file is unreadable (although this last change should not be a big deal).

Using /var/run which should be local to the computer is good, but not allowing
the user to tweak the files created by pam_ssh is an important departure from
the upstream so I think this should be certain that it is needed.

Comment 19 Dmitry Butskoy 2005-08-15 16:45:19 UTC
  During one year of using pam_ssh, we never read these files directly. Is it
actually needed for most users? Even advanced users? 
  What practical cases when the user logins passing pam_ssh, but the same
ssh-agent is necessary for him?

  I agree that it is some departure from upstream. Therefore I did not send
/var/run patch upstream. (I consider it is mostly Fedora-related).
  But at least for Fedora it is needed. IMHO, it is in the RedHat style, and
should be useful for most Fedora users. 

Comment 20 Patrice Dumas 2005-08-15 17:20:38 UTC
I personnaly used these files. I enabled pam_ssh only when loging in from gdm or
a login, so when I login through ssh it could be usefull.

Also I had to manually delete the files when the computer or the session crashed
without removing it. Admitedly if it is a computer crash te files should be
removed by the initscripts but if the computer cannot be rebooted then only root
can remove them. Even if the user cannot delete the file I believe that emptying
them should do the trick.

Maybe I should add that the pam_ssh modules are optionnal in my setup. 

Comment 21 Patrice Dumas 2005-08-15 17:32:44 UTC
I propose for the summary :

Smmary: PAM module for use with SSH keys that can launch the agent

Comment 22 Ville Skyttä 2005-08-15 17:41:08 UTC
To me that summary sounds like it's the keys that would launch the agent. 

Comment 23 Patrice Dumas 2005-08-15 17:44:51 UTC
And that:

Summary: PAM module for use with SSH keys, launching agent if needed

Comment 24 Dmitry Butskoy 2005-08-15 19:01:25 UTC
May be:

Summary: PAM module for use with SSH keys and ssh-agent


  I think these files may be made world-readable (r--r--r--). It should not lead
to security problems as the corresponding information (ssh agent`s pid and
socket) can be received other way (using "ps" command ans "ls /tmp"). 
  You really believe it is useful for all users? Access to local ssh-agent by
extern, non-related remote login may be useful, but "will never be recommended"
by Fedora people, as I guess. Therefore IMHO we should not focus pam_ssh for
this case.

Comment 25 Dmitry Butskoy 2005-08-15 19:10:51 UTC
  By the way, our examples (using pam_ssh together with new pam_console ability
to authenticate login user):


auth       required
auth       sufficient
auth       required service=system-auth
auth       optional try_first_pass
auth       required
account    required service=system-auth
password   required service=system-auth
# close should be the first session rule
session    required close
session    required service=system-auth
session    optional
session    optional
# open should be the last session rule
session    required multiple open


auth       required
auth       sufficient
auth       required service=system-auth
auth       optional try_first_pass
auth       required
account    required service=system-auth
password   required service=system-auth
session    required service=system-auth
session    optional
session    optional

  The result is one password typing for all consoles and gdm (pam_console) and
for all crypted keys to access remote hosts (pam_ssh) .

Comment 26 Patrice Dumas 2005-08-15 21:51:03 UTC

I'll use the last Summary you proposed.

Regarding the use of pam_ssh related ssh-agent information I didn't said that
users sould use the information setup by pam_ssh. But the same user login with
or without pam_ssh should be able to use that information.

Imagine that your setup is used on the computer zeus, your login is dumas.
pam_ssh is used for pam.d/login and pam.d/gdm but not for pam.d/sshd. There is
an ssh server running on zeus. You login at zeus gdm, this starts an ssh-agent.
Now you walk to another room and login with ssh to zeus. If you can read the
information setup by pam_ssh, like
eval `cat /var/run/pam_ssh/dumas`, you will use the agent. 

It doesn't means that other user need have access to your pam_ssh information
but you need to have that access.

It is possible if file is 
-r--r--r--   root user
Or if file is
-r--------   user user
In that case the user may modify the file content (but not remove it).

If you think that this sis a usefull feature, please implement the one 
you prefer in your patch, otherwise I could do it too.

Comment 27 Dmitry Butskoy 2005-08-15 22:52:18 UTC
  I shall think about it and probably implement some variant in my patch,


  What your opinion on it? (comment #18, comment #24, comment #26, ...)

Comment 28 Tom "spot" Callaway 2005-08-16 00:59:34 UTC
Well, I think you should run the idea past the upstream maintainer. If he thinks
its a good idea to make the permissions restrictive, then I'd go with that.
There is certainly precedent in pam for doing a restrictive model.

Comment 29 Dmitry Butskoy 2005-08-16 11:41:22 UTC

  As there is a "stand-alone" patch (pam_ssh-1.91-getpwnam.patch), you can now
just use the session phase for your remote ssh login.
  It was impossible with the current upstream version, because it does not allow
to use the session phase separately from the auth phase. (Typically., SSH keys
are used for remote ssh login authentication, not pam auth).
  Now you can just use /etc/pam.d/sshd as:

auth       required service=system-auth
auth       required
account    required service=system-auth
password   required service=system-auth
session    required service=system-auth
session    optional

  (Make sure sshd`s option "UsePrivilegeSeparation" is set to "no", IMHO).
  As you see, there is no more necessity to "cat /var/run/pam_ssh/<user>" by the
unprivileged user.
  Does this way satisfy you?

  Is there any other practical cases where the files should be user-readable? If
not, let`s keep the present restrictive variant. If somebody will complain, we
shall change it at the next updating.

Comment 30 Patrice Dumas 2005-08-16 14:40:15 UTC
This additionnal feature is indeed very suitable for the use I have of pam_ssh.
However this force the sysadmin to use pam_ssh for every authentification channel.
I still think that the user should be able to see the content of that file.

The change should be documented anyway, in the man page.

Comment 31 Dmitry Butskoy 2005-08-16 15:18:10 UTC
  There is no any information leaks if we made "r--r--r--" permissons. Typical
contents of such files is:

SSH_AUTH_SOCK=/tmp/ssh-nRQKz11544/agent.11544; export SSH_AUTH_SOCK;
echo Agent pid 11545;

  Agent pid can be always found by anyone using "ps" command, auth sock can be
found by "ls -l /tmp", etc. 

  I have not found files under /var/run which would not belong to root (or other
special account), therefore I don`t want to make these files owned by a user.

  What do you mean "documented anyway in the man page" ?  There is no mention in
 pam_ssh.8 about ~/.ssh/agent-* files, therefore nothing to change...

Comment 32 Dmitry Butskoy 2005-08-16 15:32:16 UTC

  Get the changed /var/run patch (makes "r--r--r--"):

Comment 33 Patrice Dumas 2005-08-16 17:07:21 UTC
Thanks Dmitry, I am fine with your updated patch. Regarding documentation I know
it wasn't documented but I added some documentation nevertheless to show how the
fedora package differs from the upstream.

The new srpm is here:

For me it is ready to publish.

Comment 34 Dmitry Butskoy 2005-08-16 20:16:17 UTC
  pam_ssh-1.91-man_agent_files.diff: first, the word "Fedora" must begins Upper
case :-) . Second, we should mention /var/run/pam_ssh/* filename, but IMHO the
comment about upstream is extra. The majority of users, even advanced, do not
know what "upstream" means... Anyway, pam_ssh.8 is not a place where it should
be noted.

  About dependencies: 
  IMHO "openssh-clients" always implies "openssh" too, may be specify
"openssh-clients" only.
  And we must specify "Requires: openssl". "Openssh" implies it currently, but
it is hypothetically possible that openssh uses another ssl-library (gnutls or
mosilla-nss) :-)

Comment 35 Patrice Dumas 2005-08-17 08:37:59 UTC
I will replace "upstream" with original. And if the place where it should be
noted isn't pam_ssh.8, where is it? In pam_ssh.8 there is allready a fair amount
of technical information, I think it shouldn't be bad to have that there. The
README seems to terse to me for that use.

Regarding dependencies:
I removed openssh from Requires.
We should not require openssl, and openssh doesn't require it. It requires, just like pam_ssh and this dependency is picked up automatically
by rpm. So if another library is used it will be picked up automatically too,
still anothere devel package would have to be precised in BuildRequires.
I even removed pam from the requires as it is picked up by

I have checked that pam_ssh builds in mock. Here is the next srpm:

Comment 36 Dmitry Butskoy 2005-08-17 10:11:47 UTC
  comment #34, comment #35 -- IMHO these are cosmetic things, do not want to
discuss about it.


  For me, the package is ready too.

Comment 37 Tom "spot" Callaway 2005-08-17 14:40:26 UTC
Good work guys. Close this when its built in the buildsystem.

Comment 38 Dmitry Butskoy 2005-08-23 10:07:19 UTC

  What your plans about completion of this package (add to cvs etc.)?

Comment 39 Patrice Dumas 2005-08-24 21:02:20 UTC
I now need to be sponsored, I think. Could it be done by you or by Tom? I cannot
find the Sponsors page on the wiki.

Comment 40 Tom "spot" Callaway 2005-08-25 01:24:36 UTC
Patrice, I'll sponsor you. Go ahead and do your paperwork.

Comment 41 Patrice Dumas 2005-08-26 08:23:11 UTC
Dmitry, do you want to be CCed for each bug report?

Comment 42 Dmitry Butskoy 2005-08-27 14:37:35 UTC
Yes, Patrice, sure!

Comment 43 Patrice Dumas 2005-08-27 21:23:42 UTC
So I added you to the owner.list. Tell me if you don't want to.

Comment 44 Patrice Dumas 2005-09-01 09:53:26 UTC
I have built the pam_ssh package on all platforms. I made a mistake on FC-4 by
doing the make tag before cvs commit, so the tag was recorded but not applied
and after I commited I couldn't tag because the tag allready existed. So I added
.1 to the release of FC-3 and FC-4 packages. If I am not wrong this should allow
for updating between fc versions as 1.fc3 < 1.fc4 < fc5. 

Comment 45 Dmitry Butskoy 2005-09-01 11:10:03 UTC
  May be FE admins can fix this mistake? (See

  Anyway, currently it looks little bit ugly...

Comment 46 Tomas Mraz 2005-09-01 12:44:44 UTC
1.fc3 < 1.fc4 < fc5  - this isn't right

fc5 < 1.fc3 < 1.fc4 is the correct ordering.
So you should rebuild the fc5 version too.

But it is possible to move the mistaken tag after the commit (too late now if
you built the 1.fcx packages) - simply use:
make tag TAG_OPTS=-F

Comment 47 Tom "spot" Callaway 2005-09-01 20:25:41 UTC
Or, just bump all three spec files to 2%{?dist}, retag them all, and rebuild
them all.

Comment 48 Patrice Dumas 2005-09-02 07:33:45 UTC

Comment 49 Dmitry Butskoy 2011-06-07 13:11:59 UTC
Package Change Request
Package Name: pam_ssh
New Branches: el6
Owners: buc

Comment 50 Jason Tibbitts 2011-06-07 15:09:50 UTC
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.