web-dev-qa-db-ja.com

SSH許可が拒否されました（公開鍵）

ローカルマシン（ubnutu 12.04 LTSも実行）からlinode（ubuntu 12.04 LTSを実行）に接続しようとしています

ローカルマシンで秘密鍵と公開鍵を作成し、公開鍵をlinodeのauthorized_keysファイルにコピーしました。ただし、linodeにsshしようとすると、「Permission denied（publickey）。」というエラーメッセージが表示されます。

キー認証を使用してWindowsマシンからsshを実行できるため、linodeでsshをセットアップする方法に問題はありません。

ローカルのubuntuマシンの.sshディレクトリにid_rsaファイルとid_rsa.pubファイルがあります。ローカルマシンにauthorized_keysファイルを作成する必要がありますか？

編集：これは、ssh -vvv -i id_rsa [youruser] @ [yourLinode]を実行したときに得られるものです。

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
serverpermissionsssh
107
Pattle

PubKeyAuthentication

クライアントをセットアップする

  1. キーを生成します
    • ssh-keygen
  2. キーを使用するようにsshを構成する
    • vim ~/.ssh/config
  3. サーバーにキーをコピーします
    • ssh-copy-id -i /path/to/key.pub SERVERNAME

ステップ2の設定ファイルには、次のようなものが必要です。

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

IdentitiesOnly yesを追加して、認証中にsshがIdentityFileを使用し、他のキーファイルを使用しないようにすることができます。これにより、問題が発生する可能性があります。

トラブルシューティング

  1. 「-vvv」オプションを使用
  2. サーバーにPUBLICキー（.pub）があることを確認してください。
  3. IdentiyFileがPRIVATEキーを指していることを確認してください。
  4. .sshディレクトリーに700があり、ファイルに700の許可（rwx ------）があることを確認してください。
  5. tail -f /var/log/auth.log（サーバー上）およびログイン試行時のエラーの監視
  6. キーファイルが多数ある場合は、IdentitiesOnly yesを試して、指定された1つのキーを使用するように認証を制限してください。
90
earthmeLon

問題は許可と所有権に起因する場合があります。たとえば、ルートとしてログインする場合、/root、.ssh、およびauthorized_keysはルートに属している必要があります。そうしないと、sshdはそれらを読み取ることができないため、ユーザーがログインを許可されているかどうかを判断できません。

ホームディレクトリで：

chown -R your_user:your_user .ssh

権利については、.sshには700、authorized_keysには600を使用してください

chmod 700 .ssh
chmod 600 .ssh/authorized_keys
57
Buzut

クライアントにauthorized_keysは必要ありません。

生成したキーを実際に使用するようにssh-clientに指示する必要があります。それにはいくつかの方法があります。タイプssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]をテストするためだけに。サーバーに接続するたびにパスフレーズを提供する必要があります。

それがうまくいった場合は、ssh-agentでキーをssh-add .ssh/id_rsaに追加できます（これにはパスフレーズを1回だけ入力する必要があり、ログアウト/再起動しない限り機能します）

14
guntbert

/etc/ssh/sshd_configのPasswordAuthenticationの値も確認し、noである場合は、yesに変更します。その後、sshサービスを再起動することを忘れないでください。

10
iman

私が抱えていた問題は、クライアントで間違ったキーを使用していたことでした。 id_rsaとid_rsa.pubを別の名前に変更しました。それらの名前をデフォルトに戻すか、sshコマンドを発行するときに次のように使用します。

ssh -i ~/.ssh/private_key username@Host
7
Todd

また、（サーバー上の）ユーザーのホームディレクトリが実際にsshを実行するユーザーに属していることを確認します（この場合はroot：rootに設定されています）。

になるはずだった：

Sudo chown username:username /home/username;
7
canoodle

最近、Webサーバーでこの問題に遭遇しました。

私は通常、~/.ssh/authorized_keys2にすべてのサーバー上の認証済みキーのリストを保持しています。私の経験から、sshdはデフォルトで~/.ssh/authorized_keysまたは~/.ssh/authorized_keys2を探します。

私のウェブサーバーの場合、/etc/ssh/sshd_configにはこの行がありました

AuthorizedKeysFile    %h/.ssh/authorized_keys

の代わりに

AuthorizedKeysFile    %h/.ssh/authorized_keys2

後者を適用し、sshデーモンを再起動し、pubkeyを使用してsshでログインする問題を解決しました。

3
Justin C

別の原因として、/etc/ssh/sshd_confのAllowedUsers構成が考えられます。注：リストはスペースで区切られています（コンマで区切られていません）。

AllowUsers user1 user2 user3
2
cmbind55

一部の人は、sshアクセスをrootアカウントでのみキーとなるように設定してから、新しいユーザーを作成し、必要があることに気付いていないかもしれません

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

その後、再試行してください。 [user]を新しいユーザーアカウントに置き換えます。

これは、セットアップでssh-keysを使用したときにDigitalOceanで新しいサーバーをセットアップするときによく起こります。

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-18-04

1
LpLrich

これは私のために働いたものであり、修正は私のものではありませんが、誰かが同じ問題を抱えている場合に備えて、ここに書き留めておきます。

元の著者はここに投稿しました： digital-ocean-public-access-key-denied

Sudo nano /etc/ssh/sshd_config

これを交換してください

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

これとともに

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

ファイルを保存してsshを再起動します

reload ssh

sshはパスワードを要求するようになりました

1
mau

Ubuntu 16.04でも動作します。

問題はsshd_configファイル内にあります

ULTIMATEソリューションは次のとおりです。

Ubuntuサーバーへのルートとしてログインします

vi /etc/ssh/sshd_config

ここで一番下に移動して、値を「no」から「yes」に変更します。

次のようになります。

Noに変更して、トンネル化されたクリアテキストパスワードを無効にします。

PasswordAuthentication yes
service sshd reload

有効にするために。

これで、ローカルマシン（ラップトップなど）から次のコマンドを使用してキーを簡単に作成できます。

したがって、新しいターミナルウィンドウを開き、サーバーにログインせずに、次のコマンドを入力します。

ssh-copy-id john @ serverIPAddress

（johnをユーザー名に置き換えます）。

あなたは行くべきです

1
Galapagos

通常のユーザー（例：johndoe）の公開キーをcPanel CentosシステムからAWSのUbuntuサーバーにコピーするときにも同じ問題がありました。 gertvdijk で示唆されているように、私は/var/log/auth.logをチェックし、Authentication refused: bad ownership or modes for directory /home/johndoeと言っていることを確認しました。 /home/johndoeをApache2のデフォルトの仮想ホストドキュメントルートとして設定しようとしたときに、（[そのタスクにも必要ありません] /home/johndoe/public_htmlを誤って777 'したことが判明しました。

回答もご覧ください here および here

サーバーは.ssh/authorized_keysに公開キーを持つだけで、クライアント（作業中のコンピューター）は秘密キー（.pem、またはFilezillaでSFTPを使用している場合、.ppk）を持つ必要があります。

1
site80443

私の場合、クライアントはubuntu 14.04ltsで、サーバーはcygwinを実行している2012サーバーで勝ちました。 cygwinの2012サーバーディレクトリが/ home/Administratorであったときに、「ssh [email protected]」を使用していました。したがって、大文字と小文字が区別され、「ssh [email protected]」（Administratorの大文字のAに注意）を試してみたところ、うまくいきました。

「ユーザーが見つかりません」などのエラーメッセージが表示されると、「アクセス許可が拒否されました（publickey、keyboard-interactive）」よりもはるかに迅速にソリューションにアクセスできます。

1
Kent

このスレッドにアクセスした私のようなPuTTYユーザーの場合、ユーザーuser @ Ipの追加を忘れた場合にもこのエラーが発生する可能性があります。

その他は、600へのキーファイルchmodの許可です）

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh [email protected] -i /path/to/.pem file
1
Alex Punnen

質問で説明したのと同じ問題がありました。クライアントマシンでssh -vvv -i id_rsa [youruser]@[yourLinode]を実行した場合の出力は、質問で説明したものと同様でした。他の回答でアドバイスされているように、すべてのファイルとディレクトリのアクセス許可を確認しましたが、それらは正しいものでした。

生成されたファイルid_rsa.pubをサーバーマシンにコピーするとき、ファイル~username/.ssh/authorized_keysとして、誤って最初からWord ssh-rsaを省略しました。それを追加することで問題は解決しました。

1
Teemu Leisti

他のすべてが失敗した場合は、ログインユーザーがsshのAllowedGroupに属していることを確認します。つまり、ユーザーはサーバー上の/etc/ssh/sshd_configの次の行に示されているグループのメンバーです。

AllowGroups ssh #Here only users of 'ssh' group can login
1
biocyberman

私の場合、問題は古いマシンから.sshディレクトリをコピーすることによって引き起こされました。私の古いSSH構成ではDSAキーが使用されていたことが判明しました。DSAキーは deprecated 今回はRSAベースの新しいキーペアに切り替えると、問題が解決しました。

0
Glutanimate

MachineAとmachineBに個別にアクセスできる場合（machineCからなど）、次の方法が機能する場合があります。

Ssh-copy-idが機能していない場合、パスワード認証が無効になる可能性があります。 次は回避策です。

MachineAの公開キーをmachineBの承認済みキー（つまり〜/ .ssh/authorized_keys）に含めると、machineAからsshを実行できます。これはscpにも適用されます。

ssh-keygenを使用してキーペアを生成した後

machineAで、cat ~/.ssh/id_rsa.pubを実行します

サンプル出力：

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

印刷されたキーをコピー（⌘ Command+C、 または CRTL+C）次に、それをmachineBの〜/ .ssh/authorized_keysファイルに追加します。

たとえば、machineBで次を実行します。

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys

0
anask