Subject: Re: [libssh2] Requirement of public key for client authentication

Re: [libssh2] Requirement of public key for client authentication

From: Dan Fandrich <>
Date: Thu, 22 Mar 2007 13:27:49 -0700

On Wed, Mar 14, 2007 at 11:58:24AM -0700, I wrote:
> The function libssh2_userauth_publickey_fromfile(), as used in the example
> scp.c and sftp.c programs, takes arguments for both the public and private
> keys of the user. However, the -i option in OpenSSH's scp and ssh takes
> only the private key to perform the same operation. Is there a way to have
> libssh2 require only the private key?

I did some investigating into this and discovered what's going on.
The SSHv2 protocol *requires* that the public key be sent by the client
to the server, so my impression that OpenSSH didn't do that was wrong.
What it does do when given the -i option is to silently look for a file
in the same location but with a .pub extension. If it's found, it
loads that file and assumes it contains the public key.

But OpenSSH still makes a connection even if I delete the .pub file. The
way that works (at least for DSA keys) is that the public key is actually
contained within the private key file! So, the .pub key file isn't even
needed at all and everything just works.

So, what I would like to see change in libssh2 is
libssh2_userauth_publickey_fromfile_ex() so that if the passed-in
publickey pointer given is NULL, it attempts to read the public key from
the private key file and if found, continue normally. I found that in
OpenSSH's case, the call to EVP_PKEY_get1_DSA() reads the DSA public key
into the returned key structure. Someone better acquainted with OpenSSL
than I will need to figure out how to accomplish this in libssh2.

>>> Dan

--              The web change of address service
          Let webmasters know that your web site has moved
Take Surveys. Earn Cash. Influence the Future of IT
Join's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
libssh2-devel mailing list
Received on 2007-03-22