7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

Mac Server にパスワード認証で SSH 接続できない

Last updated at Posted at 2019-09-02

Overview

Mac Server の SSH 設定でとてもとてもハマったので備忘録を残します。

何が起こったか?

ある Mac Server に、パスワード認証でログインできなくなった。

$ ssh dareka@mac-001.co.jp
dareka@mac-001.co.jp's password:
Permission denied, please try again.
dareka@mac-001.co.jp's password:
Permission denied, please try again.
dareka@mac-001.co.jp's password:
jibun@mac-001.co.jp: Permission denied (publickey,password,keyboard-interactive).

$ ssh dareka@mac-002.co.jp
Password:
mac-002:~ dareka$ # 別の機体はすんなりログインできる...

$ ssh jibun@mac-001.co.jp 
mac-001:~ jibun$ # また自分の private key を使えばすんなりとログインできる...

原因究明

パスワード聞かれる時の表示が若干違うし、最初は困惑しましたが原因は /etc/ssh/sshd_config の設定で、この UsePAM yes がコメントアウトされていたことが原因でした。

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
# UsePAM yes

コメントアウト外せばパスワード認証できるようになりました。
ざっくり訳してみると以下みたいなかんじ。

この設定を有効にすると、ChallengeResponse 認証とパスワード認証を通して PAM 認証が許可されます。PAM の設定によっては、ChallengeResponse 認証経由の PAM 認証はパスワードなしの RootLogin 設定の迂回路となってしまうかもしれません。ただ PAM 認証なしで PAM アカウントとセッションのチェックがしたいだけだったら、この設定は有効にして PasswordAuthentication と ChallengeResponseAuthentication は no にしてください。

PAM 認証とは、
Pluggable Authentication Module: 各種の認証処理を実行するモジュール群と、それを利用するための標準的なAPI を備えたライブラリからなるユーザー認証システム。
OS によるユーザ認証を独立させ、各アプリケーションが使用できる共通部品としてモジュール化したものをPAMと呼び、PAM は Solaris、HP-UX、FreeBSD、Linux など幅広いシステムで使用されている。
とのことらしいです。

sshd を再起動した方がいいよー、という記事も見かけましたが自分は特に再起動しなくても反映されました。

sudo launchctl stop com.openssh.sshd

ちなみに、/private/etc/ssh にも sshd_config がありますが、こちらが実態でルートの方が symlink みたいです。(linux との互換性を考慮してかな...? 詳しい方教えてください :bow: )

mac-001:~ jibun$ ls -l /etc
lrwxr-xr-x@ 1 root  admin  11  9  2 15:13 /etc -> private/etc

/private/etc/ の直下にも sshd_config ありましたが、このファイルを変更しても変更内容が反映されませんでした。編集対象は /private/etc/ssh の下の sshd_config ということに注意が必要そうです。

知っておいた方がよかったこと

問題は解決しましたが、もっと知っておいた方がよかったなー、と思ったことを書いておきます。

SSH の種類

  • パスワード認証
  • 公開鍵(+秘密鍵)認証
  • SSH1 における rhosts 認証
  • SSH1 における ChallengeResponse(TIS) 認証
  • SHS2 における keyboard-interactive 認証 (パスワード認証とほぼ同意?)

パスワード認証と公開鍵認証は必須。

公開鍵認証時の注意点

  • .ssh ディレクトリの permission は 700
  • authorized_keys の permission は 600
  • authorized_keys の owner は root になっていないか

SSH の設定ファイル

  • /etc/ssh/ssh_config → クライアント側の設定ファイル
  • /etc/ssh/sshd_config → サーバー側(SSHされる側・デーモン)の設定ファイル

sshd_config の設定

  • 公開鍵認証のみ有効にしたい場合は ChallengeResponseAuthenticationPasswordAuthenticationno にする
7
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
7
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?