46

インスタンスを作成したら、gcutil または ssh を使用してログインできます。インスタンスの下部にリストされている ssh リンクからコピー/貼り付けを試みましたが、同じエラー メッセージが表示されます。

4

11 に答える 11

46

アクセス許可拒否エラーは、SSH 秘密鍵認証が失敗したことを示している可能性があります。gcutil が推奨する Debian または Centos イメージから派生したイメージを使用していると仮定すると、次のいずれかになります。

  1. -issh キーチェーンにロードされた ssh キーがなく、オプションでプライベート ssh キーを指定していません。
  2. ログインしようとしているアカウントの .ssh/authorized_keys のエントリと一致する ssh キーはありません。
  3. マシンに存在しないアカウントにログインしようとしているか、root としてログインしようとしています。(デフォルトのイメージでは、ルートへの直接ログインが無効になっています。ほとんどの ssh ブルート フォース攻撃は、ルートまたは脆弱なパスワードを持つその他のよく知られたアカウントに対するものです。)

インスタンスにあるアカウントとキーを特定する方法:

標準の Compute Engine Centos および Debian イメージで毎分実行されるスクリプトがあり、メタデータ サーバーから「sshKeys」メタデータ エントリをフェッチし、必要に応じて (sudoers アクセスで) アカウントを作成します。このスクリプトは、sshKeys メタデータに「account:\n」という形式のエントリを想定しており、1 つのアカウントの authorized_keys に複数のエントリを入れることができます。(または、必要に応じて複数のアカウントを作成します)

イメージの最近のバージョンでは、このスクリプトはその出力を syslog 経由でシリアル ポートに送信するだけでなく、マシンのローカル ログにも送信します。を介してシリアル ポート出力の最後の 1MB を読み取ることができますgcutil getserialportoutput。これは、マシンが SSH 経由で応答しない場合に便利です。

仕組みgcutil ssh:

gcutil ssh次のことを行います。

  1. でキーを探し、存在しない場合はキーを作成するため$HOME/.ssh/google_compute_engineに呼び出します。ssh-keygen
  2. sshKeys次のようなエントリのプロジェクト メタデータ エントリの現在の内容を確認します。${USER}:$(cat $HOME/.ssh/google_compute_engine.pub)
  3. そのようなエントリが存在しない場合は、そのエントリをプロジェクト メタデータに追加し、メタデータの変更が反映され、VM 内のスクリプトが新しいエントリを認識して新しいアカウントを作成するまで、最大 5 分間待機します。
  4. 新しいエントリが配置されると (または user:key が既に存在する場合はすぐに) 、VM に接続するためのいくつかのコマンドライン引数を指定してgcutil ssh呼び出されます。ssh

これが壊れる可能性のあるいくつかの方法と、それらを修正するためにできること:

  1. を読み取るスクリプトを削除または変更した場合sshKeys、コンソールとコマンド ライン ツールは、変更が機能しないことを認識sshKeysせず、上記の自動魔法の多くが壊れる可能性があります。
  2. raw を使用しようとしているssh場合、キーが見つからない可能性があります.ssh/google_compute_engine。gcutil sshを使用するか、ssh 公開鍵 (末尾が ) をコピーしてコンソールのプロジェクトまたはインスタンスのエントリに.pub追加することで、これを修正できます。sshKeys(おそらくローカルマシンのアカウント名と同じユーザー名も入力する必要があります。)
  3. を使用したことがない場合gcutil sshは、ファイルがない可能性があり.ssh/google_compute_engine.pubます。を使用ssh-keygenして新しい SSH 公開/秘密キー ペアを作成しsshKeys、上記のように に追加するか、 を使用gcutil sshしてそれらを作成して管理することができますsshKeys。
  4. 主にコンソールを使用している場合、エントリのアカウント名がsshKeysローカルのユーザー名と一致しない可能性があります。SSH に-l引数を指定する必要がある場合があります。
于 2013-05-25T22:14:01.463 に答える
3

ホーム ディレクトリと、接続しているホストのユーザーのホーム ディレクトリのアクセス許可が 700 に設定されていることを確認します (ユーザー rwx を所有しているのは、他のユーザーが .ssh サブディレクトリを参照できないようにするためだけです)。

次に、~/.ssh ディレクトリも 700 (ユーザー rwx) であり、authorized_keys が 600 (ユーザー rw) であることを確認します。

~/.ssh ディレクトリの秘密鍵は 600 または 400 にする必要があります (ユーザー rw またはユーザー r )

于 2014-04-25T09:17:47.973 に答える
3

私は長い間この問題に直面していました。最後にssh-addの問題でした。Git ssh クレデンシャルは考慮されていませんでした。

次のコマンドが機能するかどうかを確認します。

ssh-add
于 2016-05-02T12:28:40.867 に答える
1

作成したばかりのコンピューティング エンジン VM に接続した後、同様のメッセージ [私の場合は "アクセス許可が拒否されました (publickey)"] が表示されました。この投稿を読んだ後、もう一度試してみることにしました。

その時はうまくいきました。したがって、2回目に機能する3つの理由が考えられます。

  • 2 回目の接続で問題が解決する (ssh キーが最初に作成された後)、または
  • おそらく、コンピューティング エンジンが作成された直後にコンピューティング エンジンに接続しようとすると、しばらくすると問題が解決する可能性があります。
  • この投稿を読むだけで問題が解決します

最後はありそうもないと思います:)

于 2014-03-11T14:15:02.450 に答える
0

あなたは答えを受け入れていないので、PuTTYで私のために働いたのは次のとおりです。

ここに画像の説明を入力

ユーザー名の変更を許可しないと、この質問の件名がゲートウェイ マシンのエラーとして表示されます。

于 2014-02-03T11:53:12.083 に答える