After upgrading a perfectly running system from stable (3.4) to testing
(3.6) ssh failes to work ("session closed") without reason. On the same
system a downgrade of ssh (again to 3.4 - stable) solved the problem
(without changing anything else!), so I guess the problem lies within
version 3.6.1 of ssh.

The problem only appears when "pam_safeword.so.1" is active in the
"pam.d/ssh" file (upon uncommenting the entry, ssh starts to work
again). This pam-module is for Secure Computing's "Safeword Premier
Access" (hardware token). A copy of this module (for testing purposes)
can be downloaded from

http://www.securecomputing.com/download/swagent4pam110_lin.tar

If you need anything else for reproducing the error or further testing
(perhaps even a test account on our premier access server) please let me
know!

Best regards,
Alexander Majarek
--
******************************************************************
             ThinkTank (FN 190760f, HG Wien)
               Porzellangasse 4, A-1090 Wien
     Tel: +43-1-271 44 00-0; FAX: 43-1-271 44 00-20
http://www.ThinkTank.at   mailto:Office@ThinkTank.at
    PGP-Key (DH): http://www.ThinkTank.at/tt_dh.asc
     (RSA-Key: http://www.ThinkTank.at/tt_rsa.asc)
******************************************************************

Have you tried talking to Secure Computing? I don't expect there to be
very much we can do without source to the PAM module in question. The
readmefirst.txt in the tarball above lists compatibility with OpenSSH
3.1, which was before privilege separation. That's probably the problem.

Cheers,

Hi,

thanks for your prompt reply!

AFAIK 3.4 already has privilege separation, so chances are that the
problem lies somewhere else. And since the problem was introduced with
3.6 (while 3.4 works with pam_safeword.so.1 - AS WELL AS *EVERY* OTHER
PACKAGE) it seemed to me, that this has to do with ssh-3.6 (therefore
Secure Computing probably can't help me with that issue - ssh quits
without giving a reason!).

Any idea what changed from 3.4 to 3.6 that could cause this?

brgds,
Alexander

That's true, although some details of privsep have changed.

That's not too unusual ... ssh often does that when a PAM module is
broken, although there are always ways to investigate further.

Not really. Perhaps you could get the output of 'ssh -vvv' to this
server, and perhaps also run the ssh server with the -ddd option? That's
usually the first step in debugging.

Cheers,

"Alexander Majarek, Sascha, SAM" <sam@ThinkTank.at> writes:

Are you sure that you didn't upgrade something else when you moved
from 3.4 to 3.6? I'm pretty sure that 3.4 didn't depend on libc6
2.3.2-1, that's why I'm asking.

I upgraded almost EVERYTHING (dist-upgrade), BUT ... after upgrading I
succeeded to bring ssh back to work by simply (and only!) downgrading
ssh to 3.4 - that's the reason why I suspected ssh-3.6 in the first
place to be the problem.

concerning Colin Watson's suggestions: I already tried the -vvv option,
but that produced no useful information at all (at least as far as I
could see). I will try as soon as possible (probably tomorrow) with -ddd
and send the results of both options to this list ...

Alexander

It's possible you're right, but more information is always better than
less, and although it may look like rubbish it's usually very useful in
narrowing down the source of a problem.

Cheers,

Hi
	Regarding the Debian bug you reported ("ssh 3.6 and pam_safeword.so.1
incompatibility"), this been reported to be caused by a bug in the
pam_safeword module.  For details, see these threads:

http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=107784259324428
http://marc.theaimsgroup.com/?l=secure-shell&m=108023142611886