![当我注销 SSH 会话时,为什么会出现权限被拒绝的错误?](https://linux22.com/image/91786/%E5%BD%93%E6%88%91%E6%B3%A8%E9%94%80%20SSH%20%E4%BC%9A%E8%AF%9D%E6%97%B6%EF%BC%8C%E4%B8%BA%E4%BB%80%E4%B9%88%E4%BC%9A%E5%87%BA%E7%8E%B0%E6%9D%83%E9%99%90%E8%A2%AB%E6%8B%92%E7%BB%9D%E7%9A%84%E9%94%99%E8%AF%AF%EF%BC%9F.png)
我必须在大学的服务器上运行一些测试。我可以从办公室的桌面通过 ssh 访问服务器。我想在服务器上启动一个 python 脚本,该脚本将在周末运行多个测试。
办公室的桌面将在周末处于待机状态,因此即使 SSH 会话终止,该进程也必须继续在服务器上运行。
我了解nohup
和screen
,tmux
如以下问题中所述:
我现在在做什么是:
ssh username@server
tmux
python3 run_my_tests.py
-> 该脚本执行一系列subprocess.check_output
其他脚本,该脚本本身会启动一些 Java 进程。- 测试运行良好。
- 我使用 Ctrl+B、D 并分离会话。
- 执行此操作时,
tmux attach
我重新获得 tmux 会话仍然运行良好,没有任何错误。我持续检查了几分钟,测试运行良好。 - 我关闭 ssh 会话
之后如果我通过 SSH 登录服务器,我做我能够重新连接到正在运行的tmux
会话,然而我看到的是这样的:
Traceback (most recent call last):
File "run_my_examples.py", line 70, in <module>
File "run_my_examples.py", line 62, in run_cmd_aggr
File "run_my_examples.py", line 41, in run_cmd
File "/usr/lib64/python3.4/subprocess.py", line 537, in call
with Popen(*popenargs, **kwargs) as p:
File "/usr/lib64/python3.4/subprocess.py", line 858, in __init__
restore_signals, start_new_session)
File "/usr/lib64/python3.4/subprocess.py", line 1456, in _execute_child
raise child_exception_type(errno_num, err_msg)
PermissionError: [Errno 13] Permission denied
即产生我正在运行的测试的进程,SSH 会话结束后立即,完全无法生成其他子进程。我已经chmod
编辑了所有涉及的文件的权限,没有任何变化。
我相信服务器使用 Kerberos 进行登录/权限,服务器是 Scientific Linux 7.2。
当我从 ssh 会话注销时,是否有可能删除生成新进程的权限?我能做点什么吗?我必须启动一些测试,不知道需要多少时间或空间......
- 版本
systemd
是219 - 文件系统是 AFS,使用
fs listacl <name>
我可以确认我确实拥有脚本使用的目录/文件的权限。
答案1
谢谢马克·普洛特尼克我能够识别并解决问题。
问题在于两者之间的相互作用AFS文件系统由服务器和处理身份验证的 Kerberos 使用。同样的问题在这个问题关于SO。
基本上发生的情况是,当我 ssh 进入服务器时,Kerberos 向会话提供身份验证令牌。此令牌还用于访问 AFS 文件系统。关闭 SSH 会话时,此令牌将被销毁,并且正在运行的进程在尝试访问 AFS 上的文件时开始出现权限被拒绝错误。
解决此问题的方法是在screen
/内启动一个新窗口tmux
并启动命令:
kinit && aklog
之后,您可以从screen
/分离tmux
并安全地关闭 ssh 会话。
上面的命令创建新的 Kerberos 令牌并将其与screen
/tmux
会话关联,这样当 ssh 连接关闭时,初始令牌将被撤销,但由于子进程现在使用您创建的令牌,因此它们不会遇到权限被拒绝的错误。
总结一下:
ssh username@server
tmux
- 启动您需要继续运行的进程
- 创建一个新窗口Ctrl+B, C
kinit && aklog
- 从会话中分离Ctrl+B, D
- 关闭 ssh 会话
答案2
此类错误可能与文件系统权限有关。你能看一下服务器端的系统日志事件吗?
也许您需要在您的环境中保持登录状态看看这里了解更多有关 Linux 文件权限和问题的信息,可能会有所帮助。
答案3
尝试screen ssh $USER@$HOSTNAME
在服务器上。
该kinit && aklog
解决方案对我不起作用,但我找到了这个“sshception”解决方案。在 screen 中,我通过 ssh 连接到同一台计算机,并在该 ssh 会话中运行我的程序。即使 screen 失去权限,内部的 ssh 会话也会保持打开状态并经过身份验证。