問題タブ [azure-cloud-shell]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
azure - クラウド シェルを使用して Azure 上の Linux VM に SSH 接続する
Azure クラウド シェルを使用して、Azure 上の Linux VM に SSH で接続したいと考えています。それらにはパブリック IP がなく、仮想ネットワーク上にあります。これを行う方法を知っている人はいますか?
azure - curl で拒否された Azure Kudu アクセス
Azure Kudu Web ページで提案されているように、curl から Azure アプリ ログ ストリームにアクセスしようとしています。私はWindows 10コマンドプロンプトを使用しています。これは私が試しているコマンドラインの例です:
myApp
: は Azure App Service の名前です。myUserName
:- Visual Studio パブリッシュ プロファイルで使用される Web 展開プロファイルから取得した資格情報を使用してみました。つまり、ユーザーが次のように見え
$myApp
、パスワードが 60 文字の長い文字列である場合です。 - また、Azure ポータル > MyApp > 展開資格情報からユーザー レベルの展開資格情報を作成しようとしました。ここでは、展開/FTP ユーザー名とパスワードを要求します。
- Visual Studio パブリッシュ プロファイルで使用される Web 展開プロファイルから取得した資格情報を使用してみました。つまり、ユーザーが次のように見え
どちらの場合も、curl は Web ページ タイトル401 - Unauthorized: Access is denied due to invalid credentials のコンテンツを表示します。. また、ユーザー名を二重引用符で囲み、ドル記号 ($) を円記号 (\) でエスケープしてみました。運がない。
本当にばかげたことをしているに違いない。SOの公式 Kudu docs、msdnなど、いくつかのドキュメントと投稿を確認しましたが、指示に従っていると思います。その他の情報源: MSDN 再び、古い seirer の投稿。
編集
提案の後、https://myApp.scm.azurewebsites.net/basicauthにユーザー レベルのデプロイ資格情報と VS Web デプロイ資格情報 (エスケープされたものとエスケープされていないもの) を使用してアクセスしようとしましたが、うまくいきませんでした。以前に間違えた場合に備えて、ユーザーレベルのパスワードも再度保存しました。
次に、curl から Insomnia クライアントに切り替えました。
basicauth
ユーザー レベルのデプロイ資格情報と Web デプロイ資格情報の両方を使用して をクリックすると、実際の Kudu ページが正しく表示されます。
をヒットするapi/logstream
と、両方の資格情報で、リクエストが返されないように見えます。これは、ログ出力からの継続的なフローによるものだと思います。
そのため、Insomnia クライアントとは対照的に、コマンド ラインからの curl で何かおかしなことが起こっているようです。私が使用しているカールバージョン:
curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
リリース日: [未リリース]
プロトコル: dict file ftp ftps http https imap imaps pop3 pop3s smtp smtps telnet tftp
機能: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL
curl に戻ります。
-u
オプション (およびパスワード プロンプト)をドロップし、 Insomnia によって生成された基本認証ヘッダーを手動で追加すると、すべて問題ありません。オプションの受け渡し
を使用すると、すべて問題ありません。そのため、プロンプトでパスワードを入力する方法に実際に何かがあるようです。-u
myUserName:myPassword
編集#2
繰り返しますが、@David Ebbo の提案の後、詳細な curl 出力は、計算された Base-64 トークンが間違っているように見えることを示しています。
- 作業中のものは、単一の
=
. -v
代わりに curl 出力に表示されるものは、 double で終わる 20 文字の長さ=
です。- どちらも最初の 17 文字は同じです。
thisによると、末尾の改行がパスワードの一部として使用されていることが原因である可能性があります。しかし、とにかく、ここから先に進む方法がわかりません。この時点では、何が起こっているのかを理解するだけの問題であり、回避策は既に存在します。完全を期すために、(編集された)詳細ログを次に示します。