Mike Patterson
2018-03-13 12:05:40 UTC
I'm a relatively new curl user and I'm hoping to get some feedback on an
uncommon sftp/ssh authentication feature and its support in libcurl and the
command-line tool.
In particular, I am attempting to use ssh certificates to authenticate. By
this, I don't mean populating the authorized_keys file on server. I mean
signing the user public key and making the signing user CA available as a
trusted cert on the server, and then have the client include the signed
public key (id_rsa-cert.pub) as part of the authentication. I know that's a
vague explanation. This site explains it better:
https://blog.habets.se/2011/07/OpenSSH-certificates.html.
On to my question: is this feature supported via command-line? I am able to
set-up an OpenSSH server correctly and use an OpenSSH client to
authentication in this manner. However, when I attempt with curl, I cannot.
An example of my syntax is at the bottom.
This type of SSH performs public key authentication in two stages,
requiring a resume/continue interaction with the client between them. The
command line seems to handle the first stage correctly. However, the
resume/postpone reply from the server that separates the two stages is not
handled correctly. In particular, the libcurl code expects a positive
return code (ie success) from the first stage or assumes failure, and in
the case of assumed failure, it attempts the next authentication type and
then closes the connection. I believe the correct course for the client is
to recognize the resume/continue return code and (re)send the required
parameters, etc.
If what I explained above is correct, then the curl command line does not
support this feature. I'm wondering if anyone can explain a fault in my
analysis and help me correct what's wrong. Alternatively, if someone has
implemented this form of authentication via libcurl, that would give me
reason to believe I should attempt the same, and not be concerned about the
command-line limitation, assuming there is one, as I may be operating it
incorrectly.
Here is an example syntx for my command:
curl sftp://34.216.250.169 --user IVU_User: -vvv -k --key ./id_rsa --pubKey
./id_rsa-cert.pub
* Rebuilt URL to: sftp://34.216.250.169/
* Trying 34.216.250.169...
* TCP_NODELAY set
* Connected to 34.216.250.169 (34.216.250.169) port 22 (#0)
* SSH MD5 fingerprint: 527a1d73dbcfc05c3606e05be225a3eb
* SSH authentication methods available: publickey
* Using SSH public key file './id_rsa-cert.pub'
* Using SSH private key file './id_rsa'
* SSH public key authentication failed: Callback returned error
* Failure connecting to agent
* Authentication failure
* Closing connection 0
curl: (67) Authentication failure
Any feedback if appreciated.
Mike
uncommon sftp/ssh authentication feature and its support in libcurl and the
command-line tool.
In particular, I am attempting to use ssh certificates to authenticate. By
this, I don't mean populating the authorized_keys file on server. I mean
signing the user public key and making the signing user CA available as a
trusted cert on the server, and then have the client include the signed
public key (id_rsa-cert.pub) as part of the authentication. I know that's a
vague explanation. This site explains it better:
https://blog.habets.se/2011/07/OpenSSH-certificates.html.
On to my question: is this feature supported via command-line? I am able to
set-up an OpenSSH server correctly and use an OpenSSH client to
authentication in this manner. However, when I attempt with curl, I cannot.
An example of my syntax is at the bottom.
This type of SSH performs public key authentication in two stages,
requiring a resume/continue interaction with the client between them. The
command line seems to handle the first stage correctly. However, the
resume/postpone reply from the server that separates the two stages is not
handled correctly. In particular, the libcurl code expects a positive
return code (ie success) from the first stage or assumes failure, and in
the case of assumed failure, it attempts the next authentication type and
then closes the connection. I believe the correct course for the client is
to recognize the resume/continue return code and (re)send the required
parameters, etc.
If what I explained above is correct, then the curl command line does not
support this feature. I'm wondering if anyone can explain a fault in my
analysis and help me correct what's wrong. Alternatively, if someone has
implemented this form of authentication via libcurl, that would give me
reason to believe I should attempt the same, and not be concerned about the
command-line limitation, assuming there is one, as I may be operating it
incorrectly.
Here is an example syntx for my command:
curl sftp://34.216.250.169 --user IVU_User: -vvv -k --key ./id_rsa --pubKey
./id_rsa-cert.pub
* Rebuilt URL to: sftp://34.216.250.169/
* Trying 34.216.250.169...
* TCP_NODELAY set
* Connected to 34.216.250.169 (34.216.250.169) port 22 (#0)
* SSH MD5 fingerprint: 527a1d73dbcfc05c3606e05be225a3eb
* SSH authentication methods available: publickey
* Using SSH public key file './id_rsa-cert.pub'
* Using SSH private key file './id_rsa'
* SSH public key authentication failed: Callback returned error
* Failure connecting to agent
* Authentication failure
* Closing connection 0
curl: (67) Authentication failure
Any feedback if appreciated.
Mike