或者同样的东西，但是语法不同

curl http://username:password@api.somesite.com/test/blah?something=123

在某些API中它可能不起作用(比如rabbitmq)。

还有其他选择:

curl http://username:password@example.com

curl http://admin:123456@example.com

上面的格式也可以在浏览器中使用。

要让密码至少不弹出在你的.bash_history:

curl -u user:$(cat .password-file) http://example-domain.tld

你也可以这样发送用户名:

curl -u USERNAME http://server.example

然后Curl将要求您输入密码，并且密码将不会在屏幕上显示(或者如果您需要复制/粘贴该命令)。

向curl传递凭据最安全的方法是提示插入凭据。这是在传递前面建议的用户名(-u username)时发生的情况。

但是如果不能通过这种方式传递用户名呢? 例如，用户名可能需要是url的一部分，而只有密码是json有效负载的一部分。

tl;博士: 下面是在这种情况下如何安全地使用curl:

read -p "Username: " U; read -sp "Password: " P; curl --request POST -d "{\"password\":\"${P}\"}" https://example.com/login/${U}; unset P U

Read将提示从命令行输入用户名和密码，并将提交的值存储在两个变量中，以便在后续命令中引用并最终取消设置。

我将详细说明为什么其他解决方案都不理想。

为什么环境变量不安全

Access and exposure mode of the content of an environment variable, can not be tracked (ps -eww ) since the environment is implicitly available to a process Often apps grab the whole environment and log it for debugging or monitoring purposes (sometimes on log files plaintext on disk, especially after an app crashes) Environment variables are passed down to child processes (therefore breaking the principle of least privilege) Maintaining them is an issue: new engineers don't know they are there, and are not aware of requirements around them - e.g., not to pass them to sub-processes - since they're not enforced or documented.

为什么直接在命令行中输入它是不安全的 因为运行ps -aux的任何其他用户最终都可以看到您的秘密，因为它列出了为每个当前运行的进程提交的命令。 这还因为您的秘密最终会出现在bash历史记录中(一旦shell终止)。

为什么在本地文件中包含它是不安全的 对文件的严格POSIX访问限制可以降低这种情况下的风险。但是，它仍然是文件系统上的一个未加密的文件。

简单地说，最安全的方法是使用环境变量来存储/检索凭据。因此，curl命令如下:

curl -Lk -XGET -u "${API_USER}:${API_HASH}" -b cookies.txt -c cookies.txt -- "http://api.somesite.com/test/blah?something=123"

然后调用您的restful api，并将API_USER和API_HASH的Base64编码值传递给http WWW_Authentication头。lk只是告诉curl遵循http 30x重定向并使用不安全的tls处理(即忽略ssl错误)。而double——只是bash语法中停止处理命令行标志的糖。此外，-b cookie .txt和-c cookie .txt标记处理cookie， -b发送cookie， -c本地存储cookie。

手册中有更多认证方法的示例。