更新系统后踩的一些坑,望周知~

#python not found

1
bad interpreter: /usr/bin/python: no such file or directory

我的定时脚本的报错,找了之后发现新系统把python或者说python2移除了,想用要自己装,只能用python3

1
#!/usr/bin/python3

#sshd 配置重置

还好我有备份配置的习惯,不然我的电脑在公网下可以访问,然后 ssh 的密钥验证也被重置了的话,是真的很危险。

默认修改的配置项

然后关于这个ChallengeResponseAuthentication,去查了好多资料,感觉这个比较好理解,👇:

PasswordAuthentication controls support for the ‘password’ authentication scheme defined in RFC-4252 (section 8). ChallengeResponseAuthentication controls support for the ‘keyboard-interactive’ authentication scheme defined in RFC-4256. The ‘keyboard-interactive’ authentication scheme could, in theory, ask a user any number of multi-facited questions. In practice it often asks only for the user’s password.

If you want to fully disable password-based authentication, set BOTH PasswordAuthentication and ChallengeResponseAuthentication to ‘no’. If you’re of the belt-and-suspenders mindset, consider setting UsePAM to ‘no’ as well.

Public/Private Key-based authentication (enabled by the PubkeyAuthentication setting) is a separate type of authentication that does not involve sending user passwords to the server, of course.

Some would argue that using ChallengeResponseAuthentication is more secure than PasswordAuthentication because it is more difficult to automate. They therefore recommend leaving PasswordAuthentication disabled while leaving ChallengeResponseAuthentication enabled. This configuration also encourages (but does not necessarily prevent) use of publickey authentication for any automated system logins. But, since SSH is a network-based protocol, the server has no way to guarantee that responses to ChallengeResponseAuthentication (a.k.a. ‘keyboard-interactive’) are actually being provided by a user sitting at a keyboard so long as the challenge(s) always and only consists of asking a user for her password.

#参考链接