web-dev-qa-db-ja.com

ユーザー名とパスワードでcURLを使う？

ユーザー名/パスワードが必要なURLにアクセスしたいのですが。 curlでアクセスしてみたいのですが。今私は次のようなことをしています。

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

エラーが出ます。上記のコマンドと一緒にユーザー名とパスワードを指定する必要があると思います。

どうやってやるの？

curlcredentials
386
user246114

ユーザ名を含めるには-uフラグを使用してください。curlはパスワードの入力を要求します。

curl -u username http://example.com

コマンドにパスワードを含めることもできますが、パスワードはbash履歴に表示されます。

curl -u username:password http://example.com
584
Finbarr

より安全です。

curl --netrc-file my-password-file http://example.com

...コマンドラインで単純なユーザー/パスワード文字列を渡すのは悪い考えです。

パスワードファイルのフォーマットは（man curlによる）：

machine <example.com> login <username> password <password>

注意：

  1. マシン名は 不可 でなければなりませんhttps://または同様のもの！ホスト名だけです。
  2. 単語 'machine'、 'login'、および 'password'は単なるキーワードです。実際の情報はそれらのキーワードの後のものです。
203
Pierre D

または同じものだが異なる構文

curl http://username:[email protected]/test/blah?something=123
69
Daniel Magnusson

次のように書いてユーザー名を送ることもできます。

curl -u USERNAME http://server.example

Curlはそれからあなたにパスワードを尋ねるでしょう、そしてパスワードはスクリーン上に見えないでしょう（あるいはあなたがコマンドをコピーするか貼り付ける必要があるなら）。

60
Kristian

パスワードを安全にスクリプトで渡す（つまりps auxfやlogsで表示されないようにする）には、-K-フラグ（stdinから設定を読み込む）とheredocを使用します。

curl --url url -K- <<< "--user user:password"
16
Matt Fleming
curl -X GET -u username:password  {{ http://www.example.com/filename.txt }} -O
11
user128364

あなたの.bash_historyにパスワードが表示されないようにするには：

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

わかりやすく簡単に言えば、最も安全な方法は、環境変数を使用して資格情報を保存/取得することです。したがって、curlコマンドは次のようになります。

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

それからあなたの安らかなapiを呼んで、そしてWWW_AuthenticationとAPI_USERのBase64エンコード値でhttp API_HASHヘッダーを渡します。 -Lkは、http 30xリダイレクトに従うことと、安全でないtl処理を使用すること（すなわち、sslエラーを無視すること）をcurlに指示するだけです。二重の--は、単にコマンドラインフラグの処理を止めるための単なるbash構文シュガーです。さらに、-b cookies.txtおよび-c cookies.txtフラグは、-bがCookieを送信し、-cがCookieをローカルに格納することでCookieを処理します。

マニュアルにはもっと 認証の例 methodsがあります。

6
Dwight Spencer

とても簡単です、以下を実行してください。

curl -X GET/POST/PUT <URL> -u username:password
4
Preyas

Gnomeキーリングアプリがあるシステムを使用している場合、パスワードを直接公開しないようにするには、 gkeyring.py を使用してキーリングからパスワードを抽出します。

server=server.example.com
file=path/to/my/file
user=my_user_name
pass=$(gkeyring.py -k login -tnetwork -p user=$user,server=$server -1)

curl -u $user:$pass ftps://$server/$file -O
3
Eliot Blennerhassett

他の回答では、私が読んだことに基づいて、netrcがユーザー名とパスワードを指定することを提案しています。構文の詳細は次のとおりです。

https://ec.haxx.se/usingcurl-netrc.html

他の答えと同様に、私はこの質問に関して安全保障に注意を払う必要性を強調したいと思います。

私は専門家ではありませんが、これらのリンクは洞察力に富んでいます。

https://ec.haxx.se/cmdline-passwords.html

要約する：

暗号化されたバージョンのプロトコル （HTTPS対HTTP）（FTPS対FTP）を使用すると、ネットワークリークを回避するのに役立ちます。

netrc を使用すると、コマンドラインのリークを回避できます。

さらに一歩進めて、gpgを使ってnetrcファイルを暗号化することもできるようです

https://brandur.org/fragments/gpg-curl

これであなたの信任状は平文として「安静」（保存）されません。

3
Brian Davis

通常CURLコマンドは

curl https://example.com\?param\=ParamValue -u USERNAME:PASSWORD

パスワードが設定されていない場合やコマンドをスキップする場合は、単純にパスワードの入力を要求します。パスワードセクションは空白のままにします。

すなわちcurl https://example.com\?param\=ParamValue -u USERNAME:

3
Touseef Murtaza

私はbash（Ubuntu 16.04 LTS）で同じ必要性を持っていました、そして答えで提供されたコマンドは私のケースではうまくいきませんでした。私は使用しなければなりませんでした：

curl -X POST -F 'username="$USER"' -F 'password="$PASS"' "http://api.somesite.com/test/blah?something=123"

-F引数内の二重引用符は、変数を使用している場合にのみ必要です。そのため、コマンドラインから... -F 'username=myuser' ...を使用することになります。

コメントや編集でその理由を説明できたらうれしいです。

2
Marco

あなたはのようなコマンドを使用することができます、

curl -u user-name -p http://www.example.com/path-to-file/file-name.ext > new-file-name.ext

それからHTTPパスワードは引き起こされます。

参照： http://www.asempt.com/article/how-use-curl-http-password-protected-site

2
Deepak R

資格情報をcurlに渡す最も安全な方法は、資格情報を挿入するように指示されることです。これは、以前に提案されたようにユーザー名を渡すときに起こることです（-u USERNAME）。

しかし、そのようにユーザー名を渡すことができない場合はどうなりますか？ 例えば、ユーザー名はURLの一部で、パスワードだけはJSONペイロードの一部である必要があるかもしれません。

tl; dr： この場合、curlを安全に使用する方法は次のとおりです。

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

readは、コマンドラインからユーザー名とパスワードの両方の入力を求め、送信された値を2つの変数に格納します。これらの変数は後続のコマンドで参照され、最後に設定解除されます。

他の解決策が理想的ではない理由を詳しく説明します。

環境変数がなぜ安全ではないのか

  1. 環境変数がプロセスに対して暗黙的に使用可能であるため、環境変数の内容のアクセスおよび公開モードを追跡できません（ps -eww）。
  2. 多くの場合、アプリは環境全体をつかんでデバッグや監視の目的でログに記録します（特にアプリがクラッシュした後は、ディスク上のプレーンテキストのログファイルに記録されることがあります）。
  3. 環境変数は子プロセスに渡されます（したがって、最小特権の原則を破ります）
  4. それらを維持することは問題です：新しいエンジニアは彼らがそこにいることを知りません、そして彼らが強制されたり文書化されていないので彼らの周りの要求を意識しません。

コマンドラインで直接コマンドを入力するのは安全ではないのはなぜですか / _あなたの秘密はps -auxを実行している他のユーザーから見えるようになってしまうためです。また、あなたの秘密はbashの履歴に入ります（Shellが終了すると）。

ローカルファイルに含めるのが危険な理由 ファイルに対する厳密なPOSIXアクセス制限により、このシナリオのリスクを軽減できます。ただし、それはまだファイルシステム上のファイルであり、保存時には暗号化されていません。

0
iammyr