Key-based authentication for SSH/SFTP

[Mark Sellan]

I have 2 servers with keys setup to allow sftp/ssh connections between the same account on each server node to be used in a script. That part is working. I set up DSA keys and placed the public key in each server/user's authorized_key file.

The problem began when I received a request from our programming group to provide that same functionality between our servers and a third party/external server.

Unfortunately, the third party server runs Windows and PGP. I was expecting to exchange public keys with them, but they say that our DSA public key will not work with their system.

So I'm trying to figure out the best course of action. Should the DSA public keys generated by ssh-keygen be compatible with the DSA public keys generated by PGP? If not, do I need to install GPG (PGP) on HP-UX?

Thanks very much,

-mark

[Ivan Krastev]

Possible solution is to install freesshd on the Windows server and do the same as Unix boxes.

regards,
ivan

[Steven Schweda]

SSH and PGP (or GnuPG) are separate worlds,
and do not share key infrastructure.

Were you planning to do SSH/SFTP things with
the Windows server? Does the Windows server
have SSH/SFTP software installed (and
configured, and permitted for use by you)?

If you're planning to exchange encrypted data
with people who have only PGP (or GnuPG),
then you'll need to get PGP (or GnuPG). I
haven't looked at the details, but I gather
that, used correctly, GnuPG can interoperate
with PGP, which may obviate investing in any
non-free PGP software for HP-UX.

I use GnuPG hardly at all, and almost
exclusively on VMS, but it should be easily
available on/for HP-UX.

http://gnupg.org/

[Mark Sellan]

Ivan,

Thank you for the suggestion...unfortunately, the third party is unwilling/unable to install any additional software on their systems. That's what made me wonder if installing GPG on our systems would help or not?

[Steven Schweda]

If the folks at the other end have PGP, then
GnuPG (suitably configured) at your end
should provide a solution. You'll need to do
some reading to find the fine print involved
for GPG-PGP interoperability, but that should
be possible.

What could go wrong?

[Steven Schweda]

I'd make sure that they really have PGP, and
not GnuPG, and whatever they really do have,
I'd ask them what its version is, so that,
when nothing works, you'll at least know what
isn't working with whom, so you'll be able to
describe your desperate situation properly
when it all starts swirling around the drain.

If they actually had GnuPG, it'd all be more
likely to work with minimal thought.

[Mark Sellan]

Thanks for the responses...to answer some of the questions:

1. We have just started a relationship with the third party and they were not expecting us to automate our processes. We need to transfer files back and forth between our system and theirs and want to do it using a script.

They were expecting one of our staff to use an sftp client and manually log in and out of their systems. So the idea of using a process to login and do the transfers is new for them. I think we are the first to request such functionality (of them).

2. I believe they are running PGP because it was listed in the header, along with the version, of the public key file they sent us.

So some more questions....If I can get beyond potential compatibility issues between PGP on Windows and GPG (GnuPG) on HP-UX, is there anything I need to do to configure SSH/SFTP to use the GPG keys?

I am only familiar with using ssh-keygen and the authorized_keys file to set up this functionality. Any ideas about how to get SFTP/SSH to use GPG keys?

Thanks much,

-mark

[Bill Hassell · Accepted solution]

I don't believe there is any compatibility between SSH and PGP keys with the OpenSSH software on HP-UX, so no, it won't work. The keygen program does have the ability to convert the commercial SSH keys to OpenSSH keys, but not PGP keys. (see -e and -i options in ssh-keygen).

However, modern PGP packages should have the ablity to convert a PGP key to OpenSSH and that public key can used on HP-UX. Or look at purchasing a commercial version of SSH for HP-UX that supports PGP keys: http://www.ssh.com/products/client-server/

[Steven Schweda]

> [...] is there anything I need to do to
> configure SSH/SFTP to use the GPG keys?

Re-write the SSH software? As I said, to the
best of my knowledge, "SSH and PGP (or GnuPG)
are separate worlds, and do not share key
infrastructure." You use SSH keys with SSH
(or SFTP) and GnuPG (or PGP) keys with GnuPG
(or PGP). And ne'er the twain shall meet.

The real question here is whether you're
supposed to 1) use SFTP for the file
transfer, in which case you'll probably want
to exchange SSH keys, or 2) use GnuPG/PGP
encryption on the data, and any old FTP (or
similarly insecure) scheme for the file
transfer, in which case you'll need to
exchange GnuPG/PGP keys.

Scheme 1 involves only SSH/SFTP for
encryption and data transfer, so it'd
probably be simpler to use. It also requires
SSH/SFTP software at both ends, and you cast
doubt on its availability at the other end.

Scheme 2 involves separate encryption
(GnuPG/PGP) and data transfer (Plain old
FTP? Kermit over a dial-up modem? UPS
shipping magnetic tape? Punched paper tape
through a pneumatic tube?), where the data
transfer itself may be insecure, because the
data being transferred have already been
scrambled.

It's not clear which of these you're trying
to do.

> They were expecting one of our staff to use
> an sftp client and manually log in and out
> of their systems.

If they have an _S_FTP server, then they must
have SSH/SFTP software. If they don't have
SSh and an SFTP server, then you'll have a
tough time using "an sftp client" to do
anything, whether manually or automatically.

> 2. I believe they are running PGP because
> it was listed in the header, along with the
> version, of the public key file they sent
> us.

You mean like this?:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9b (VMS Alpha)

mQGsdu0ifKhekVjihsSdibHeoiEdfhi[...]
[... big block of nonsense ...]
=CL8q
-----END PGP PUBLIC KEY BLOCK-----

or this?:

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3a

mQCNsdu0ifKhekVjihsSdibHeoiEdfhi[...]
[... big block of nonsense ...]
A0A=
=qQlF
-----END PGP PUBLIC KEY BLOCK-----

That would be a GnuPG or PGP (respectively)
key (in text, "ASCII armored" (not binary)
form). Showing your non-secret bits would
have been useful here. (I showed you mine,
...)

> Any ideas about how to get SFTP/SSH to use
> GPG keys?

Nope. Don't believe you can.

Resume the argument with your opponent, and
decide how you are supposed to transfer the
data. If this involves SSH/SFTP, then
exchange the appropriate (SSH) keys. If it
involves some insecure communication method
(FTP, UPS, ...), then exchange GnuPG/PGP
keys, and get hold of some GnuPG software (or
genuine PGP, if you prefer) for your end.

When you know how the data transfer will be
done, _then_ you can worry about how to
automate it. It's probably easier with SFTP,
but a Forum search for something like
FTP script
should find oodles of examples of ways to
push or pull files using FTP automatically.

[Steven Schweda]

> Nope. Don't believe you can.

> However, modern PGP packages should have
> the ablity [...]

Hey. What do I know? As I said, I don't use
this stuff much.

[Mark Sellan]

Thanks to Bill and Steven! (points coming soon...)

This is much much clearer now. The GPG option on HP-UX doesn't get me much as I cannot use (by policy here) an insecure protocol (ftp) to do the data transfer.

The third party I need to exchange files with *has* an SSH/SFTP server running on some Windows machine since they've provided manual login instructions for a person to use with a client.

So, it sounds like I need to persuade the third party to figure out what SSH software they have and use it to generate keys for the userids they've given us to login to their system. Then those keys could be exchanged with ours to allow an automated script to SFTP between us and them?

At the worst it seems, if I am successful in persuading them, there is the possibility that there still may be some conversion necessary of SSH keys between our OpenSSH and whatever ssh they have?

Am I on the right track now?

Thanks again,

-mark

[Mel Burslan]

You have not mentioned if this process of manually logging in to this server then getting and putting files then logging out procedure is working for you or not, but if it is working fine in manual operation, you might want to invest a little time in setting up expect on your hpux server and use expect scripting (I am sure you'll find it easy enough) to automate the process.

My 2 cents.

[Mark Sellan]

Mel,

The process is working manually...but the nature of the data makes the manual process really cumbersome....

We actually started with Expect and are developing that solution alongside the key authentication route. So if the key authentication with SSH/SFTP doesn't work out I guess the Expect script will be our plan B.

-mark

[Matti_Kurkela]

If you're the one that logs in to the other party's system, you should generate your own SSH keypair and send the public key to the other party. This way, there is no need to transfer a private key at all.

Note that there are basically two competing file formats for SSH public keys: the OpenSSH format and the "ssh.com SSH" format. The key data is 100% compatible between the formats: it is just packaged differently.

OpenSSH's public key is one _long_ line of text. The "ssh.com" format wraps this into multiple lines with a nice, fixed line length, and adds PGP-like wrapper lines.

OpenSSH's ssh-keygen command has -e (export to ssh.com format) and -i (import from ssh.com format) options to handle this exact problem.

An example procedure for creating a DSA keypair for OpenSSH and creating a ssh.com style version of the public key:

$ cd $HOME
$ ssh-keygen -t dsa
(accept the default key file location, do whatever you wish with the passphrase)
$ ssh-keygen -e -f .ssh/id_dsa.pub > .ssh/id_dsa.ssh_com.pub

Now ~/.ssh/id_dsa.pub contains an OpenSSH-formatted public key, and ~/.ssh/id_dsa.ssh_com.pub contains the same key in ssh.com format.

MK

[Mark Sellan]

Thanks Matti, this helps clarify the idea of the keys and how they are packaged. And for clarity, for future readers if nothing else, we had sent them our public key (nothing in this post was ever intended to indicate we were talking about exchanging private keys...) and they said it was incompatible with their system and sent us a copy of their public key, as a sample of what they wanted, which turned out to be a PGP key.

So, we had a phone conference with them today and asked them to try to figure out what commercial SSH software they are using on their Windows server so we can figure out how to get them a file with our public key that will allow our script to login to their systems using SFTP.

I appreciate the info about converting between OpenSSH and commercial SSH keys, which it sounds like we're gonna need.

thanks,

-mark