[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PAM bashing (was Re: kerberos support in ssh/lsh)
>>>>> "Niels" == Niels =?UNKNOWN?Q?M=F6ller?= <firstname.lastname@example.org> writes:
Niels> I don't want to use PAM in lshd, for those reasons:
Niels> I wouldn't recommend anyone to use PAM for network
You may be interested to know, but I posted your message on
debian-devel (where lots of pro-PAM people exist), and too my
surprise, they entirely agree with you.
The original messages can be found at
However to summarise them:
>>>>> In article <20001019225520.F5589@visi.net>, Ben Collins <email@example.com> writes:
Ben> As the PAM maintainer, I agree totally. In OpenSSH, PAM
Ben> support is a complete hack. I had to do cartwheels to get the
Ben> current implementation working as good as it is. Mostly to do
Ben> with the fact that ssh has no terminal with the client during
Ben> authentication and arbitrary isn't possible until after the
Ben> authentication is complete.
>>>>> In article <Pine.LNX.3.96.1001019203002.7396Q-100000@wakko>, Jason Gunthorpe <firstname.lastname@example.org> writes:
Jason> On 20 Oct 2000, Brian May wrote:
>> The upstream author of lsh (GPL replacement for ssh v2) has
>> said quite strongly (in the heimdal-discuss mailing list) that
>> he is not going to support PAM, as the design of ssh doesn't
>> support PAM.
Jason> If he doesn't support PAM for password only authentication
Jason> and environment setup then he is making a grave mistake and
Jason> we will have to patch it before it could really be properly
Jason> used in Debian..
Jason> PAM has a major failing when dealing with non-local
Jason> authentication methods (:<) but this basically degenerates
Jason> into meaning you can't use some neat modules (like OTP),
Jason> you can't use CHAP systems, and you can't use things that
Jason> don't make sense (like local smart card readers on the
Jason> Supposidly PAM does have a binary authenticator interface
Jason> (I don't know the details, but this is supposidly how the
Jason> Kerb stuff works) but the trouble is that it isn't really
Jason> workable because the protocol is set by PAM (he got this
Jason> But, you *can* use pam for the simple case of authorizing a
Jason> single password rather well. (he got this right too)
Jason> However, there is a whole area that PAM does rather well
Jason> at, and that is local environment setup, control and such
Jason> forth (session, account, password changing, etc). This is a
Jason> fairly common use, for instance all the Debian.org servers
Jason> use PAM to perform home directory creation on login. PAM
Jason> modules provide MOTD's, wtmp logging, etc that were
Jason> traditionally provided by applications.
Jason> This is a big, important feature that he completely
Jason> overlooked. IMHO even if PAM is a failure at arbitary
Jason> protocol authentication it succeeds here at least.
>> I wondered: how does openssh cope?
Jason> It has a pseudo 'chat' (right word?) function that only
Jason> responds with the network password from the client. This is
Jason> about the best you can do with the old ssh protocol. ssh2
Jason> is supposed to be better..
Jason> Frankly, he is dead right. Someone should sit down and
Jason> extend PAM to work with arbitary CHAP systems at least, it
Jason> is a messy problem but I think solvable. This must mean
Jason> changing PAM because the network protocols are already
SASL? I will have to ask him about that.
Jason> Example: ppp-pam cannot use pam_smb to authenticate a MS
Jason> ppp user using an ecrypted password passed through to an
Jason> authorization server like Samba. IIRC this requires a
Jason> challenge to originate from the samba server, pass through
Jason> pam, get encoded by ppp, go to the client and get returned
Jason> all the way back.
I am not going to followup on this in this mailing list anymore.
Brian May <email@example.com>