Re: [Ssh-sftp-perl-users] Need help using passphrase with key pairs in Net::SFTP::Foreign

[Russ B. <us...@gm...>]

Salva,

The Department of Defense (DoD) may implement new ssh configuration
guidelines that require all installed ssh clients and servers to be
running in FIPS 140-2 compatibility mode.  Tectia corporation
(formerly named SSH.com) has obtained FIPS certification for its ssh
product. Tectia is under consideration because it would standardize
the ssh software used on Windows and UNIX servers and provide a
corporate stamp of approval that FIPS requirements have actually been
met.

While openssl has achieved FIPS certification, my concern is that it
might be difficult to prove that OpenSSH was built in a manner that
maintained openssl's FIPS validity. SUN's native client is not
currently built with a FIPS operating mode.

Presently Net::SSH::Perl and Net::SFTP are used by our automated file
transfer scripts.  The crypto packages used by these modules are not
likely to be put through the costly FIPS certification process for the
ssh client they generate.  Since Net::SFTP::Foreign controls the
installed ssh client, installing FIPS certified Tectia software is one
solution being explored. This solution seemed promising and has tested
very well in FIPS mode while the key pairs had empty passphrases.

However, another (currently draft) requirement specifies that user
passphrases be generated by FIPS certified software. The Tectia
ssh-keygen-g3 utility (in FIPS mode) will not allow key pair
generation with an empty passphrase.  This led to our testing the
Tectia software with passphrases.

I do not need a work-around immediately, since I am working to meet
currently draft standards that do not yet have an announced
implementation date. But the sooner I can chart a course of action,
the better. That is, I could migrate my scripts from Net::SFTP to
Net::SFTP::Foreign if I new for sure that the passphrase issue would
be resolved in a month or two. I could also begin the migration if I
knew that passwords could always be used instead of passphrases.

How certain is it that a passphrase work-around can be created? If
created, how long would it take, in light of your many existing
obligations?

Do you believe this Tectia passphrase issue also applies to passwords?
I can test that today.

Is passing the passphrase to stderr instead of /dev/tty an issue that
Tectia might consider for its own prompt attention?

I appreciate the time you have spent helping analyze this issue and
your willingness to implement a work-around, time constraints
permitting.

Russ

Note: I am not affiliated with Tectia in any way.  I have simply been
asked to evaluate its use in FIPS compliant mode relative to a planned
migration from Net::SFTP to Net::SFTP::Foreign.


On Thu, Oct 28, 2010 at 7:14 AM, Salvador Fandino <sfa...@ya...> wrote:
>
>
>
>
> ----- Original Message ----
>> From: Russ Brewer <us...@gm...>
>> To: Salvador Fandino <sfa...@ya...>
>> Sent: Thu, October 28, 2010 12:24:36 AM
>> Subject: Re: [Ssh-sftp-perl-users] Need help using passphrase with key pairs in
>>Net::SFTP::Foreign
>>
>> Salva,
>>
>> The attached output was generated with command:
>>
>> truss -f -o  truss.out ./test_basic_passphrase.pl
>
> Hi,
>
> That confirms my suspicion: the tectia client is not sending the passphrase
> prompt to /dev/tty but to stderr and the module does not see it.
>
> Working around that from inside the module is not going to be easy and I don't
> have the time to solve it right now or for the next days.
>
> So, we are back at logging from the outside and using the "transport" feature to
> pass back the initialized connection to the module... but before exploring that
> way I see you are in a Solaris box and the native SSH client works flawless with
> Net::SFTP::Foreign, do you have any reason to not use that client instead?
>
> - Salva
>