卷曲的SFTP密码验证失败 [英] Curl fails on sftp password authentication

问题描述

当我手动SFTP发布使用用户名和密码，它工作正常，使用curl失败的时候。同样的脚本将成功没有问题，连接到其他服务器。因为我可以手动登录和其他客户端没有问题的服务器管理员都没有太大的帮助。

When I manually sftp using username and password it works fine, when using curl it fails. The same script will successfully connect to other servers with no problem. Because I can manually log in and other clients don't have a problem the server admins aren't much help.

下面是卷曲失败的尝试：

Here is the curl failed attempt:

curl -v --insecure --user username:password sftp://someurl.com

*   Trying 199.187.***.***...
* Connected to someurl.com (199.187.***.***) port 22 (#0)
* SSH MD5 fingerprint: 6831eae63f230952a1775e0f67f80e7b
* SSH authentication methods available: publickey,gssapi-keyex,gssapi with-mic,password
* Using SSH public key file '(nil)'
* Using SSH private key file ''
* SSH public key authentication failed: Unable to extract public key from private key file: Unable to open private key file
* Failure connecting to agent
* Authentication failure
* Closing connection 0
curl: (67) Authentication failure

下面是另一个URL卷曲的成功：

Here is the curl success on another url:

curl --insecure -v sftp://username:[e-mail]

* Rebuilt URL to: sftp://username:[e-mail]/
*   Trying 199.27.***.***...
* Connected to anotherurl.com (199.27.***.***) port 22 (#0)
* SSH MD5 fingerprint: bcf5632dc06c0353849b745822c4889a
* SSH authentication methods available: password,publickey
* Using SSH public key file '(nil)'
* Using SSH private key file ''
* SSH public key authentication failed: Unable to extract public key from private key file: Unable to open private key file
* Initialized password authentication
* Authentication complete
drw-rw-rw-   3 user   group    2048 Sep 27  2014 .
* Connection #0 to host anotherurl.com left intact

下面是关于原始URL手动尝试：

Here is the manual attempt on the original URL:

[ec2-user@ip-*** scripts]$ sftp -v [e-mail]
OpenSSH_6.2p2, OpenSSL 1.0.1k-fips 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options for *
debug1: Connecting to someurl.com [199.187.***.***] port 22.
debug1: Connection established.
debug1: identity file /home/ec2-user/.ssh/id_rsa type -1
debug1: identity file /home/ec2-user/.ssh/id_rsa-cert type -1
debug1: identity file /home/ec2-user/.ssh/id_dsa type -1
debug1: identity file /home/ec2-user/.ssh/id_dsa-cert type -1
debug1: identity file /home/ec2-user/.ssh/id_ecdsa type -1
debug1: identity file /home/ec2-user/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 68:31:ea:e6:3f:23:09:52:a1:77:5e:0f:67:f8:0e:7b
debug1: Host 'someurl.com' is known and matches the RSA host key.
debug1: Found key in /home/ec2-user/.ssh/known_hosts:6
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/.ssh/id_rsa
debug1: Trying private key: /home/ec2-user/.ssh/id_dsa
debug1: Trying private key: /home/ec2-user/.ssh/id_ecdsa
debug1: Next authentication method: password
[e-mail]'s password: 
debug1: Authentication succeeded (password).
Authenticated to someurl.com ([199.187.***.***]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [e-mail]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug1: Sending subsystem: sftp
Connected to someurl.com.
sftp> ls
incoming  
sftp> 

从那些更聪明，比我的人任何帮助将大大AP preciated。

Any help from those smarter-than-me people would be greatly appreciated.

推荐答案

得到它的工作，原来是pretty简单，但只会在URL中的用户名和密码的工作。

Got it working, turned out to be pretty simple but would only work with the username and password in the url.

curl -v --insecure sftp://username:[e-mail]

这是行不通的。

curl -v --insecure --user username:urlencodedPassword sftp://somedomain.com

有人谁知道比我更很可能细说，为什么他们：第二个是行不通的。

Someone who knows more than me could probably elaborate as to why they 2nd one wouldn't work.

这篇关于卷曲的SFTP密码验证失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！