タグ付けされた質問 「ssh-agent」

10
別のユーザーへのssh-agent転送とsudo
私は私のsshキーを使ってログインすることができますその中に、サーバAを持っていると私が「sudoの秀- otheruser」能力を持っている場合は、ENV変数が削除されているので、私は、キーの転送を失うとソケットは、私の元のユーザーによってのみ読み取り可能です。「sudo su-otheruser」を介してキー転送をブリッジできる方法はありますか。そのため、転送されたキー(私の場合はgit cloneとrsync)を使用してサーバーBで処理を行うことができますか? 私が考えることができる唯一の方法は、他のユーザーと「ssh otheruser @ localhost」のauthorized_keysにキーを追加することですが、それは私が持つすべてのユーザーとサーバーの組み合わせに対して行うのは面倒です。 要するに: $ sudo -HE ssh user@host (success) $ sudo -HE -u otheruser ssh user@host Permission denied (publickey).

2
SSHエージェントから特定の転送キーを使用しますか?
Githubのキーと他のキーがあるとしましょう。ssh-add -L自宅のコンピューターAでsshエージェントに多数のキーを追加しました(たくさんの行を返します)A.で、.ssh/configどのホストでどのキーを使用するかを設定しました。 ssh -T -vvv git@github.com 2>&1 | grep Offering 与える debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github 予想どおり、1つのキーのみが提供されます。しかし、その後、いくつかのホストBにssh-ingしForwardAgent yesて同じコマンドを繰り返して、私は debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.linode2 debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.helium debug1: Offering RSA public key: /Users/doxna/.ssh/id_rsa.github つまり、すべてのキーを試します。サーバーが戻る前に限られた数のキーしか試すことができないので、これは問題Too many authentication failuresです。そこで.ssh/config、ホストBで編集して、 Host github.com IdentityFile /Users/doxna/.ssh/id_rsa.github IdentitiesOnly yes しかし、私はキーの提供を取得しませんが、むしろ debug2: key: …
30 ssh  ssh-agent 

6
CygwinのsshでPLinkとPageantを使用できますか?
現在、PuttyのPageantおよびPLinkユーティリティを使用するGUIツールのためにmsysgitを使用していますが、Cygwinを一般的なSSHターミナルとして使用しています。Cygwinでssh-agentを使用していましたが、それは両方のSSHキーマネージャーのSSHキーパスフレーズを入力する必要があることを意味します。Unixポートツール(msys、git、cygwin、Ruby Net:SSHなど)をすべて構成して、ssh-agentではなくPLink / Pageantを使用することはできますか?それがPLinkの目的の1つであるように思えますが、その方法に関するドキュメントは見つかりません。
26 ssh  putty  cygwin  ssh-agent 

7
シェルスクリプトからssh-agentを実行する
とりわけ、ssh-agentを起動し、秘密鍵をエージェントに追加するシェルスクリプトを作成しようとしています。例: #!/bin/bash # ... ssh-agent $SHELL ssh-add /path/to/key # ... これに伴う問題は、ssh-agentが$ SHELLの別のインスタンス(私の場合はbash)をキックオフすることであり、スクリプトの観点からはすべて実行され、ssh-addの下にあるものは実行されません。 シェルスクリプトからssh-agentを実行し、コマンドのリストの下を移動するにはどうすればよいですか?

1
Windows Serverの起動時にPuTTYエージェントにSSHキーを追加する方法は?
Windowsサーバーが起動するたびに、ユーザーが対話的にログオンする前に、Putty Agent(pagent.exe)にプライベートSSHキーを追加する必要があります。キーはサービスによって使用されます。 キーを使用する必要があるのが通常のユーザーである場合は、スタートアップフォルダーにショートカットを配置するだけですが、ユーザーがログインしないため、サーバーでは機能しません。 これは、Windows Server 2008とWindows Server 2003で必要です。 SSHとSFTPを使用した公開鍵認証がより広く普及しているため、これはかなり一般的なユースケースであるに違いないと考えています。

10
SSH:許可が拒否されました(publickey、gssapi-with-mic、password)
================================================= ================== 更新:host2パスワードログインを許可しない場合のsshdの構成が判明しました。これに答えた人々に感謝します。 ================================================= ================== シナリオ:私の大学のプロジェクトのために会社と仕事をしています。PuTTyを使用してhost1最初にSSHで接続し、そこからSSHで接続する必要がありますhost2(以下を参照)。host2でユーザー名とパスワードが与えられました。 host2にはまったくアクセスできないため、host2の知識はありませんsshd_config。 これは私がにSSHにしようとしていたときに何が起こったかですhost2からhost1。 ff@host1:~$ ssh -v host2 OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /home/ff/.ssh/config debug1: Applying options for * debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to host2 [192.*.*.*] port 22. debug1: Connection established. debug1: …
16 ssh  ssh-agent 

1
SSH ForwardAgentの複数のホップ
過去2時間、次の問題の解決策を探していましたが、うまくいきませんでした。 開発: サーバーに接続するために公開鍵認証を使用しています。公開/秘密鍵を管理する必要がないように、ssh-agent転送を使用します。 私はサーバーを持っているとしましょうA, B and C。 から接続する場合、これは非常にうまく機能しLOCAL ---> A ---> Bます。 私もそうすればそれは非常にうまく機能しますLOCAL ---> A ---> C。 今、試してみるとLOCAL ---> A ---> B ---> C、SSHからに接続できませんB to C。 注目に値する:私は流動性としてサーバーAに接続しますが、ルートとしてサーバーBに接続します。流動性としてサーバーBに接続すると問題は解決しますが、これは私にとって選択肢ではありません。 ユーザーの推奨に従って、ssh -A毎回使用して、エージェント転送が有効になっていることを確認します。 私は同じような質問を1つ見つけましたが、ここには答えがありません:複数のホップを介してssh-agent転送を連鎖させることは可能ですか? ここの@Zoredacheによると:https ://serverfault.com/a/561576/45671 各中間システムでクライアント構成を調整するだけです。私はそれを信じた。

1
別の非rootユーザーからのSSH_AUTH_SOCKへのアクセス
シナリオ: ローカルPCでssh-agentを実行していますが、すべてのサーバー/クライアントはSSHエージェント認証を転送するように設定されています。ローカルPCのssh-agentを使用して、すべてのマシン間を移動できます。うまくいきます。 自分自身(user1)としてマシンにSSHで接続し、 user2という名前の別のユーザー(sudo -i -u user2)に変更してから、ローカルPCで実行しているssh-agentを使用して別のボックスにsshする必要があります。ssh user3 @ machine2(user3のauthorized_keysファイルに私の公開SSHキーがあると仮定)のようなことをしたいとしましょう。 私がしているsudoを保つように構成されたSSH_AUTH_SOCKの環境変数を。 関与するすべてのユーザー(user [1-3])は、非特権ユーザー(rootではない)です。 問題: SSH_AUTH_SOCK変数が正しく設定されていても、別のユーザーに変更すると(その設定を/tmp/ssh-HbKVFL7799/agent.13799と言います)、user2は、user1によって作成されたソケットにアクセスできません。もちろん、そうでなければ、user2はuser1の秘密鍵を乗っ取り、そのユーザーとしてホップすることができます。 このシナリオは、user2のsudoを介してシェルを取得する代わりに、rootのsudoを介してシェルを取得した場合にうまく機能します。当然、rootはマシン上のすべてのファイルにアクセスできます。 質問: できればsudoを使用して、user1からuser2に変更しながら、user1のSSH_AUTH_SOCKに引き続きアクセスするにはどうすればよいですか?
11 ssh  sudo  ssh-agent 

3
ファイル名でssh-agentからIDを選択します
問題:私は20〜30 ssh-agent人のID を持っています。Too many failed authenticationsSSHでは通常、20の異なるキーでログインを試行できないため、ほとんどのサーバーはによる認証を拒否します。 現時点では、IdentityFileおよびIdentitiesOnlyディレクティブを使用して、すべてのホストのIDファイルを手動で指定しているため、SSHは1つのキーファイルのみを試行し、機能します。 残念ながら、これは元のキーが利用できなくなるとすぐに機能を停止します。ssh-add -lすべてのキーファイルの正しいパスが表示され、それらはのパスと一致しますが.ssh/config、機能しません。どうやら、SSHはファイル名ではなく公開鍵の署名によってインデンティティを選択します。つまり、SSHが公開鍵を抽出できるように、元のファイルが使用可能である必要があります。 これには2つの問題があります。 キーを保持しているフラッシュドライブを取り外すとすぐに機能しなくなります 鍵ファイルがリモートホストで利用できないため、エージェント転送が役に立たなくなる もちろん、公開鍵を自分のIDファイルから抽出して自分のコンピューターに保存したり、普段ログインしているすべてのリモートコンピューターに保存したりすることもできます。しかし、これは望ましい解決策のようには見えません。 必要なのは、ファイル名でssh-agentからIDを選択する可能性です。これにより、SSHを実行したリモートホスト上でも.ssh/config、を使用して-i /path/to/original/key、またはを渡すことで、適切なキーを簡単に選択できます。フルパスを指定する必要がないように、キーに「ニックネーム」を付けることができればさらに良いでしょう。

2
SSH鍵の問題:RSA1鍵ファイルではない不明な鍵タイプ '----- BEGIN'
backuppcサーバーはリモートマシンにrootとしてサインインしてバックアップすることができますが、backuppcユーザーとしてサインインし、同じキーを使用してこれらのマシンにsshしようとすると、次のデバッグ出力でキーが拒否されます。 OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 debug1: Reading configuration data /var/lib/BackupPC/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to XXX.XXXXXX.com [XX.XXX.XX.XX] port 222. debug1: Connection established. debug1: identity file /var/lib/BackupPC/.ssh/identity type -1 debug1: identity file /var/lib/BackupPC/.ssh/identity-cert type -1 debug3: Not …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.