カスタムユーザー$ HOMEでSSHキー認証を使用する
/home/とは異なる$ HOMEディレクトリを持つユーザーがいます。
ユーザーのホームは/pkg/homeの下にあり、/pkgの所有者は別のユーザーですが、すべてのユーザーは/pkgへのグループアクセス権を持っています。ユーザーがフルパスの所有者ではないため、SSHDはauthorized_keys（例：/pkg/home/usera/.sshd/authorized_keys）へのアクセスを制限するようです。
sshd_configがこの制限を変更するオプションはありますか？
/ pkg /の所有者は関係ありません。 useraが所有する場合は、userbなどで問題が発生します。したがって、SSHDがauthorized_keysファイルを使用できないようにする何か他のものである必要があります。このファイルが書き込み可能かどうかを確認する必要がありますのみ所有者によって、および適切なユーザーによって所有されているかどうか。同じことがすべての親ディレクトリに適用されます。
それはすべてか無かです。StrictModesオプションをオフにすると、sshdはファイルモードをチェックしません。グループ書き込み可能なディレクトリ（ユーザーがグループ内に一人でいる場合は問題ありません）など、特定の奇妙なケースが問題ないと言う方法はありません。
OpenSSHは、~/.ssh/authorized_keysとそれに含まれるディレクトリの権限と所有権を上向きに繰り返しチェックします。ただし、ホームディレクトリに到達すると比較は停止します。たとえば、認証ファイルが/home/joe/.ssh/authorized_keysで、/home/joeがユーザーのホームディレクトリである従来の配置では、/home/joe/.ssh/authorized_keys、/home/joe/.ssh、および/home/joeのみがチェックされます。
したがって、シナリオは非常に疑わしいものですが（/pkgはrootが所有し、必要に応じて追加のグループ権限が必要です）、sshに影響を与えることはありません。
シンボリックリンクが含まれている場合、sshはチェックを開始する前にすべてのシンボリックリンクを展開することに注意してください。
システムログには関連情報が含まれている場合があります。ログインに失敗したためにログメッセージが表示されるかどうかを確認してください。
カスタムポート（sshd -d -p 2222）でデバッグモードデーモンを実行して、ご使用のバージョンのsshが私のバージョン（OpenSSH 5.5p1のソースを調べた）と同じチェックを実行することを確認します。必要に応じてstrace -f -efile sshd -d -p 2222を使用して、サーバーがチェックするファイルのアクセス許可を確認します。これらの権限チェックが問題ではない場合は、-dフラグを追加すると光が当たる可能性があります。
AppArmorを使用している場合は、sshサーバーがユーザーの.sshディレクトリ内のファイルの読み取りに制限されている可能性もあります。 AppArmorとホームディレクトリが標準外の場所にある場合は、AppArmorポリシーを更新する必要があります（SSHだけでなく）。 。Xauthorityを読み取れないため、Evinceは起動に失敗します を参照してください。
ユーザーディレクトリのベースディレクトリとして「/ data」を使用して、同じ問題が発生しました。私にとっては、「restorecon -R -v〜/.ssh」を実行するだけでは不十分でした。まず、走らなければなりませんでした
# semanage fcontext -a -e /home /data
ルートとして、次に（/ dataディレクトリにルート所有のディレクトリが含まれているのと同じようにルートとして）
# restorecon -R -v /data