最初に
CentOSのお話です
鍵認証でいくら試しても、何度も権限周りを見直しても下記のように Permission denied と言われて心が折れたあなたへ。
deploy@hostname: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
TL;DR
以下の条件に当てはまる場合はSELinuxを無効にして試してみてください
- 権限まわりはモニタに穴が空くほど見直した
- SSHでログインしようとしているユーザのホームディレクトリが、/home配下以外
- SELinuxが有効
Permission denied は、権限の問題だ
本来 Permission denied であればほぼサーバ／クライアントの鍵関連の権限が問題です。
Qiitaでもこれまで何度も記事になっているので、ぐぐってください（他力本願）
それでもいくら権限周りを確認しても間違いはないよ…
もしかして、下記の条件に当てはまりませんか？もしそうならここが終着点です🐳
- SSHでログインしようとしているユーザのホームディレクトリが、/home配下以外
- SELinuxが有効
ええ、SELinuxのしわさです👿
問題切り分けのためにとりあえずの対応
SELinuxを無効にしてください。これでログインできるようになると思います。多分。
💭ただ、/var/log/audit/audit.log にそれっぽいログが見つからなかったんだよなぁ…
sudo setenforce 0
何が問題だったのか？
そもそもの原因はユーザのホームディレクトリを /home ではなく既存の別のディレクトリに配置したこと。SELinuxはディレクトリ毎に専用のラベルをもっています。
以下の home_root_t とか user_home_dir_t が今回ハマった箇所。
# ls -laZ /home
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 .
dr-xr-xr-x. root root system_u:object_r:root_t:s0 ..
drwx------. vagrant vagrant unconfined_u:object_r:user_home_dir_t:s0 vagrant
もしホームディレクトリを別のところに移す場合、上記のようなラベルを張り直さないといけないのですが、新規ディレクトリならまだしも既存のディレクトリ（たとえば var 等）の場合は用途を考えると張り直すことができない場合も😇
最後に
SELinuxは厄介なものですが、基本セキュリティを守るものです。ホームディレクトリ配下をWeb公開したりとか、今回のようにホームディレクトリを既存ディレクトリ配下にしてしまうとか、セキュリティリスクが高いものに対してきちんと守ってくれます。
ただ、とにかく存在を忘れやすいのと、ググると大体 SELinuxを無効に とあってなかなか理解が深まらないものですよね。いつか時間をかけてきちんと理解できたらいいなーと思いつつ。