web-dev-qa-db-ja.com

authorized_keysに公開キーを追加してもsshできません

私は自分にsshアクセスを与えようとしているDigital Oceanドロップを持っています。以前に何が行われたかはわかりません。 Digital Ocean UIを介して公開キーを追加しようとしました。それはうまくいきませんでした。permission denied (publickey)を取得し続けました。

Digital Oceanコンソールからサーバーにアクセスし、/root/.ssh/authorized_keysに公開キーを手動で追加しました。その後、ssh [email protected]を使用してsshを試みました。それはうまくいきませんでした（許可は拒否されました）。

そこで、新しいユーザーを追加して、/home/me/.sshディレクトリ自体にアクセス許可700を持つ.sshディレクトリを作成し、600ファイルにauthorized_keysを作成しました。次に、ssh [email protected]を試しました。それもうまくいきませんでした。

Sshデーモンを再起動しても何も変わりません。

私は何が欠けていますか？

編集：

詳細なssh出力を次に示します。

https://Gist.github.com/jaesung2061/a37cfd68308414cede8abf7f0137daa9

編集2：

LogLevel DEBUG3出力：

enter image description here

networking16.04ssh
13
Jeff

最終的にopenssh-serverを再インストールし、問題を修正しました。与えられた解決策はすべて素晴らしいですが、私にはうまくいきませんでした。何が原因で問題が発生したのかわかりませんが、前の開発者が設定を台無しにして、かなり悪い状態に台無しにした可能性があると思います。

私のような特定の問題を抱えている人はいないと思います。ただし、Digital Oceanのドロップレットがある場合、SSHアクセスを取得できず、指定された解決策のいずれも機能しないため、Digital Oceanコンソールでこれらのコマンドを実行してSSHサーバーを再インストールします。 これは破壊的なプロセスであり、/etc/ssh/の古い設定ファイルを消去することに注意してください（.sshディレクトリではありません）。

apt-get purge openssh-server
apt-get autoremove
apt-get autoclean
apt-get install openssh-server

Sshクライアント/キーが適切であると仮定すると、サーバーにSSHで接続できるはずです。

3
Jeff

クライアント構成

~/.ssh/configを設定します

sshのホストエントリを設定するのは非常に簡単で、多くの手間を省くことができます。以下に例を示します。

Host digitaloceanbox
Hostname 111.111.111.111
User root
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/digitalocean-rsa
ForwardX11 yes


Host github github.com
Hostname github.com
User git
PubKeyAuthentication yes
IdentityFile /home/user/.ssh/github-rsa
ForwardX11 no

この例では、digitaloceanboxとgithubとgithub.comをセットアップして、次のコマンドを実行できるようにします。

  1. ssh github
  2. ssh digitaloceanbox

構成ファイルで指定されているユーザーとは異なるユーザーとしてログインする場合は、最初にuser@を追加します。

  • ssh user@digitaloceanbox

sshキーの生成

ssh-keygen -t rsa -b 4096 -C user@homemachine
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):  /home/user/.ssh/digitalocean-rsa
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/user/.ssh/digitalocean-rsa
Your public key has been saved in /home/user/.ssh/digitalocean-rsa.pub.
The key fingerprint is:
SHA256:p9PYE/tveF2n//bLbp3ogYDtMtYEC5ziQiPxeob6fbo user@homemachine

ssh-keygenのプロンプトが表示されたら、生成する秘密キーの完全なパスを指定したことに注意してください。また、リモートマシン上のキーを簡単に識別できるようにするコメント（-C）も定義しました。

これにより、2つのファイルが作成されます。

  1. .ssh/digitalocean-rsa
    • PRIVATE key。 これを共有しない。
  2. .ssh/digitalocean-rsa.pub
    • 公開鍵。これは、認証のためにサーバーに保存するものです。

sshキーを提供するときは、.pubバージョンであることを確認してください!! ~/.ssh/configに追加するときは、システムに追加した公開キーと一致する正しい秘密キーを追加してください。

サーバー構成

ほとんどのインストールでは、公開キー認証が有効になっています。しかし、すべてを自由に行うことを始めると、いくつかの問題が発生する可能性があります。 OPの問題が発生した場所で、OPが/root/.ssh/ディレクトリを削除して最初からやり直すことをお勧めします。

sshを使用してリモートシステムのルートユーザーにアクセスすることはお勧めしません。別のユーザーにsshしてから、パスワード（Sudo su -）を使用してrootにエスカレーションすることをお勧めします。

ssh-copy-idを使用してホストにキーを追加します

別のユーザーを作成し、そのユーザーとしてsshを使用するか、rootユーザーとして使用するかに関わらず、サーバーにsshキーを配置する推奨方法は次のとおりです。

  1. ssh-copy-id -i /home/user/.ssh/digitalocean-rsa.pub user@digitaloceanbox

これにより、sshdが、必要な権限で必要なディレクトリとファイルを作成できます。これは、権限を台無しにしたり、詳細を覚える必要がないということを意味します。ツールを使用してキーをアップロードするだけです。

パスワード認証を無効にする

つまり、自分でキー入力し、キーを使用して接続できることを確認したら、sshdでパスワード認証を無効にし、サービスを再起動することをお勧めします。

  1. 編集/etc/ssh/sshd_config
  2. PasswordAuthentication no
  3. Sudo systemctl restart sshd

新規ユーザーはどうですか？

パスワード認証を無効にした場合、新しいユーザーにキーを設定するにはどうすればよいですか？ 1つの方法は、/etc/skelディレクトリにテンプレートファイルを追加することです。 1人のユーザーにキーを設定したら、次の手順を実行します。

  1. Sudo cp -r .ssh/ /etc/skel/
  2. ls /etc/skel/.ssh
  3. /etc/skel/.ssh/にあるすべてのファイルを編集して、新しく作成されたすべてのユーザーのキーを自動的に入力する場合を除き、空になるようにします。

Sudo useradd -m newuserを使用して新しいユーザーを作成すると、そのユーザーは.ssh/authorized_keysを持ちます。これは編集可能で、適切な権限を持ちます。

デバッグ

sshdログファイルを見て、接続が失敗するか拒否される理由を確認できます。

  1. Sudo tail -f /var/log/auth.log

このコマンドを実行しているときに、別のターミナルを使用してログインを試みます。多くの場合、提供されるメッセージは問題を特定したり、オンラインで解決策を見つけるのに役立つほど十分です。

18
earthmeLon

Sshは、sshキーを使用した所有権、ファイル、およびディレクトリのアクセス権について非常に慎重です。

〜/ .ssh /は所有者が所有し、700の権限を持っている必要があります。 〜/ .ssh/authorized_keysは所有者が所有し、600の権限を持っている必要があります。

したがって、ルートの場合：

Sudo chown root:root -R /root/.ssh/
Sudo chmod 700 /root/.ssh/
Sudo chmod 600 /root/.ssh/authorized_keys

ユーザーmeの場合：

Sudo chown me:me -R /home/me/
Sudo chmod 700 /home/me/.ssh/
Sudo chmod 600 /home/me/.ssh/authorized_keys

そして、もう一度試してください。

もちろん、/ etc/ssh/sshd_configで、rootがまったくログインできるか、sshキーだけでログインできるかを確認する必要もあります。

あなたが持っている場合 ：

PasswordAuthentication no

次に設定できます：

PermitRootLogin yes

そしてsshdを再起動します：

/etc/init.d/sshd restart

そしてさらに試みる。

Sshでは、これにsshセッションを使用している場合でもsshdデーモンを再起動できることに注意してください。Opensshはそれを処理するように設計されています。

アップロードしたログファイルスニペットを見ると、MacOSXを使用しているようです。そこで新しいsshキーを作成できますか？

さらに、過去に、ユーザーのローカルコンピューターに複数のプライベートsshキーがある場合、これによりsshを使用してリモートでログインできないことがあることがわかりました。これを解決するために、ファイル〜/ .ssh/configでローカルコンピューターにエントリを作成することは非常に役立ちました。例えば ​​：

Host my-vps
  HostName my-vps-ip-address-here
  IdentityFile ~/.ssh/id_rsa-my-private-key-location
  User my-username-here

その後、ローカルコンピューターのコマンドラインで試してください。

ssh -v my-vps

Sshキーを使用し、他の一部のログインにsshキーを使用しない場合、sshキーを使用するエントリに加えて、〜/ ssh/configファイルでsshキーを使用せずにsshログインを定義することもできます。

Host pi
  Hostname 192.168.1.111
  Port 22
  User pi
  PasswordAuthentication yes
  PreferredAuthentications password

これは私には問題ありません。コマンドラインで使用するキーを定義することもできます：

ssh -v [email protected] -i .ssh/id_rsa

これにより、デバッグが容易になり、コマンドラインでは常にローカルコンピューターで機能するはずです。

12
albert j

リンクしたログによると、クライアント側でprivate keyファイルが見つからないという問題があると思います。

  • 最初に、ローカルマシン上に~/.ssh/id_rsaファイルが存在することを確認します。これが正しいファイルです（さらにある場合）。

  • .sshフォルダーのアクセス許可（drwx------を実行しない場合はSudo chmod 700 ~/.sshである必要があります）とその内容（-rw-------を実行する場合はSudo chmod 600 ~/.ssh/*である必要があります）を確認します。リモートマシンにも同じ権限を適用します。

さらに、目的の秘密キーを使用して強制的に試行し、-iパラメーターを使用してsshに直接与えることができます。

Sshのマンページ（端末でman sshを実行）で詳細情報を取得できます。

また、rootユーザーとしてログインする場合は、ログイン前にルートアカウントを有効にして、Sudo passwd rootまたはサーバー管理ツールでパスワードを作成する必要があります（Ubutntuにはルートアカウントがありますデフォルトでは無効になっています）。詳細情報は buntu Wiki で入手できます。

それが役に立てば幸い。

3
dgonzalez

Sshデーモンの構成を再確認し（/etc/ssh/sshd_configにある必要があります）、以下を確認します。

PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

また、構成ファイルをチェックして、AllowUsersまたはAllowGroupsが設定されているかどうかを確認します。これらはそれぞれユーザーとグループのホワイトリストとして機能するためです。

また、rootユーザーにキーを追加しようとしていることに気付きました。デフォルトではルートログインは無効になっているはずですが、PermitRootLoginフィールドを使用してこれを変更することもできます。

3
TLin

Digital OceanでDebianイメージを使用すると、この問題が浮上しました。何らかの理由で簡単なセットアッププロセス中に、おそらくルートパスワードを設定したときに、/rootの所有者がユーザーdebianに変更されました。 /var/log/auth.logで次のことがわかりました：

Jul 26 20:58:17 docker sshd[12576]: Authentication refused: bad ownership or modes for directory /root

chown root:root -R /rootを実行するだけで問題は解決しました。

HTH

1
Sean Brady

よく似た問題がありました。これは私のために働いた-この行を/ etc/ssh/sshd_configに追加

AuthorizedKeysFile %h/.ssh/authorized_keys

その後、通常の方法でsshを再起動します。

0
bodycheetah