
如同上面的問題所述,我有一個專為 SSH 存取而設計的 RHEL 6 伺服器,設計上 root 無法透過 SSH 登入。當我在本機伺服器時,我可以以 root 身分登錄,但只能以 root 身分登入。如果我嘗試以使用者身分登入,螢幕會快速閃爍一則訊息:
Last Login: Mon Aug 24 08:24:52 on tty1
no directory: /home/user1!
logging in with home="/"
login: no shell: Permission denied
我得到 no shell 因為 中沒有 shell /
。
現在真正讓我困惑的是主目錄確實存在,並且包含一個有效的 shell,並且據我所知 ( 755
) 已獲得許可。對於該伺服器實例上存在和建立的所有使用者來說,這是常見的。當我創建用戶時是否定義主目錄的路徑或讓預設值負責並自動分配它似乎並不重要。
我在安全日誌或訊息日誌中沒有發現任何奇怪的東西,只是用戶成功登入(他們已經登錄,但沒有外殼就無法執行任何操作)
我希望此時不需要重新安裝,但如果這是唯一的選擇,伺服器上幾乎不會丟失任何資料。
任何幫助將非常感激,因為我已經搜索並嘗試了一周但沒有運氣。
編輯:
我useradd user1
最初使用該命令添加用戶,當這導致我使用的上述問題時
mkdir /home/user1 && useradd user1 -d /home/user1 && chown -R user:user1 /home/user
當我運行cat /etc/passwd | grep user1
命令時,我得到:
user1:x:513:517::/home/user1:bin/bash
當我運行ls -l /home
命令時,該用戶的條目是:
drwxr-xr-x. 4 user1 user1 4096 Aug 19 17:03 user1
答案1
我能夠透過運行命令來解決問題
for p in $(rpm -qa); do rpm --setperms $p; done
並重新啟動伺服器。一旦重新啟動,我不僅能夠以已建立的任何使用者身分登錄,還能夠再次使用 GUI。這表示系統上某個地方的檔案權限已損壞。我不知道它們是如何腐敗的,但現在一切都正常了。
答案2
我在您的設定中看到的唯一問題是在您的 passwd 檔案中。嘗試更改
user1:x:513:517::/home/user1:bin/bash
為
user1:x:513:517::/home/user1:/bin/bash
.
答案3
當傳遞正確的選項時,應該useradd
建立主目錄,並且您不需要(或不應該)手動建立它們。我建議您執行以下操作(按列出的順序)以正確刪除並重新建立您的使用者。
userdel -f -r user1
useradd -m user1
注意:您不必傳遞該-d
選項,因為在這種情況下將使用預設選項/home/user1
。
答案4
我剛剛在 CentOS 6 機器上遇到了同樣的問題。這是 /home 中的檔案存在錯誤標記 SELinux 安全上下文的問題。上面的評論者之一,Michael Hampton,他說檢查 /var/log/audit/audit 日誌是正確的。我聽從了他的建議,發現這裡出現了 SELinux 問題。為我解決這個問題的解決方案是:
sudo restorecon -Rv /home
這將遞歸地恢復主目錄中所有檔案的預設安全上下文標籤。之後,透過公鑰的 ssh 存取已恢復。