Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Nov 2011 16:17:03 -0600
From:      Guy Helmer <guy.helmer@palisadesystems.com>
To:        =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>
Cc:        freebsd-security@freebsd.org
Subject:   Re: Possible pam_ssh bug?
Message-ID:  <F8162819-A165-4505-987E-957D7D5D681E@palisadesystems.com>
In-Reply-To: <86ty65qecx.fsf@ds4.des.no>
References:  <98001F9B-0B96-4D17-9EAE-08B12A1C1C75@palisadesystems.com> <86ty65qecx.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 15, 2011, at 3:12 PM, Dag-Erling Sm=F8rgrav wrote:

> Guy Helmer <guy.helmer@palisadesystems.com> writes:
>> I have a shell user who is able to login to his accounts via sshd on
>> FreeBSD 8.2 using any password. The user had a .ssh/id_rsa and
>> .ssh/id_rsa.pub key pair without a password but nullok was not
>> specified, so I think this should be considered a bug.
>=20
> It turns out that this goes all the way to OpenSSL, which ignores the
> passphrase if the key is not encrypted.  The only solution I can think
> of - more of a workaround, really - is to first try to load the key =
with
> an empty passphrase, and skip the key if that worked.  See the =
attached
> (untested) patch.
>=20
> A more advanced patch would load all keys but require at least one of
> them to have a passphrase.
>=20
> DES
> --=20
> Dag-Erling Sm=F8rgrav - des@des.no
>=20
> <pam_ssh_nullok.diff>

Yes, that patch applied OK to the 8.2 test machine and resolved the =
issue with the unencrypted id_rsa private key.  I didn't know of any =
other way to check the key either - nothing jumped out at me from the =
OpenSSL API documentation.

Thanks for the quick turnaround,
Guy

--------
This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F8162819-A165-4505-987E-957D7D5D681E>