Tip

centos7 升级openssh 由于官方不再不支持选择源码编译方式 官方网站下载 https://zlib.net/ https://openssl-library.org/source/ https://www.openssh.com/portable.html zlib wget https://zlib.net/zlib-1.3.1.tar.gz tar xf zlib-1.3.1.tar.gz cd zlib-1.3.1 ./configure --prefix=/usr/local/zlib-1.3.1 sudo make sudo make install openssl wget https://github.com/openssl/openssl/releases/download/openssl-3.5.2/openssl-3.5.2.tar.gz tar xf openssl-3.5.2.tar.gz cd openssl-3.5.2 ./Configure \ --prefix=/usr/local/openssl-3.5.2 \ --openssldir=/usr/local/openssl-3.5.2/ssl \ enable-fips \ shared sudo make sudo make install openssh wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-10.0p2.tar.gz wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-10.0p2.tar.gz.asc wget https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/RELEASE_KEY.asc gpg --import RELEASE_KEY.asc gpg --verify openssh-10.0p2.tar.gz.asc gpg --edit-key 736060BA gpg> trust #然后选择 5 = I trust ultimately gpg> quit tar zxf openssh-10.0p2.tar.gz openssh-10.0p1 export PATH="/usr/local/openssl-3.5.2/bin:$PATH" export LD_LIBRARY_PATH="/usr/local/openssl-3.5.2/lib64:$LD_LIBRARY_PATH" ./configure \ --prefix=/usr/local/ssh \ --sysconfdir=/usr/local/ssh/etc \ --with-privsep-path=/usr/local/ssh/var/empty \ --with-zlib=/usr/local/zlib-1.3.1 \ --with-ssl-dir=/usr/local/openssl-3.5.2 \ --without-openssl-header-check sudo make sudo LD_LIBRARY_PATH="/usr/local/openssl-3.5.2/lib64:$LD_LIBRARY_PATH" make install 调整配置 ...

centos7 yum 源已经失效, 可以通过下面指令更换默认配置， baseurl中 mirror.* 替换为 vault* sed -i -e '/^mirrorlist/d;/^#baseurl=/{s,^#,,;s,/mirror,/vault,;}' /etc/yum.repos.d/CentOS*.repo yum update -y https://jms1.info/linux/centos7-vault.html

背景 Nginx 是现代互联网中最受欢迎的高性能 Web 服务器和反向代理服务器之一。为了充分发挥其性能，我们通常需要使用最新版本的 Nginx，并静态链接最新的依赖库（如 PCRE2、zlib 和 OpenSSL）。然而，手动下载和编译这些依赖库既耗时又容易出错。 为了解决这个问题，我在 GitHub 项目 中编写了一个脚本，可以自动化完成这一流程，大幅简化了 Nginx 的构建和安装过程。 脚本功能 自动化获取最新版本： 脚本从 GitHub 拉取以下依赖库的最新稳定版本： PCRE2 zlib OpenSSL Nginx 静态编译支持： 将所有依赖库静态编译到 Nginx 中，生成独立的二进制文件。 TLS 1.3 支持： 使用最新版本的 OpenSSL，启用 TLS 1.3 加密协议。 多操作系统兼容： 自动检测系统的包管理器（yum 或 apt），并安装所需的构建工具。目前支持： CentOS 7+ Ubuntu 24.04+ 阿里云 Linux 3 使用方法 步骤 1：下载并运行脚本 您可以通过以下命令一键下载并运行脚本： bash <(curl -L https://raw.githubusercontent.com/weida/nginx-latest-builder/main/nginx-builder.sh) 步骤 2：完成安装 脚本会自动下载、编译和安装最新的 Nginx。执行完毕后，您可以通过以下命令查看版本信息： /usr/local/nginx/sbin/nginx -V 自定义配置 脚本默认使用以下 Nginx 配置选项，您可以根据需求在脚本中修改： --with-http_ssl_module \ --with-http_v2_module \ --with-http_gzip_static_module \ --with-http_stub_status_module \ --with-http_realip_module \ --with-http_sub_module \ --with-pcre=/path/to/pcre2 \ --with-zlib=/path/to/zlib \ --with-openssl=/path/to/openssl \ --with-openssl-opt="enable-tls1_3" \ --with-cc-opt="-O2" \ --with-ld-opt="-Wl,-rpath,/usr/local/lib" 总结 通过这个脚本，您可以轻松获得一套最新的 Nginx 服务环境，无需手动下载、配置和编译依赖库，大大提升了效率。如果您对项目感兴趣，欢迎访问 GitHub 项目主页 查看详细代码并参与贡献！ ...

Deep Dive into Linux chroot: From Basics to Practical Application In Linux system management, chroot is a powerful tool that changes the root directory for a process, enabling file system isolation. This article will explain the principles of chroot in detail and demonstrate its configuration and verification with a practical example that simulates Postfix using SASL authentication. During an SMTP-related testing task on an Ubuntu virtual machine, while configuring Postfix to use SASL with sasldb for authentication, the following error occurred: ...

深入理解 Linux chroot：从原理到实战 在 Linux 系统管理中，chroot 可以通过改变程序的根目录来实现文件系统的隔离。在本文中，我们将详细介绍 chroot 的原理，并通过一个模拟 Postfix 调用 SASL 的实战演示，帮助你掌握如何正确配置和验证 chroot 环境。 在一次smtp相关测试任务中， ubuntu虚拟机中搭建postfix服务器使用 sasl 中的密码验证方式使用 sasldb 报如下错误： Sep 12 08:36:20 server postfix/smtpd[2384]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory 搜索到下面帖子：https://serverfault.com/questions/721925/postfix-smtpsaslauthd-autentication-failure，发现与chroot有关。 什么是 chroot？ chroot 是 Linux 提供的一种文件系统隔离机制，全称为 “change root”，它允许我们将某个进程及其子进程的根目录 / 改变为指定的目录。在这个受限环境中，进程只能访问新的根目录中的资源，而无法接触到系统其他部分。 chroot 的应用场景 安全隔离： 限制进程访问系统文件，提高安全性。例如，运行 Postfix 等服务时，将其置于 chroot 环境中，防止潜在的漏洞被利用。 测试和调试： 模拟不同的系统环境，调试服务或运行实验，而不会影响主系统。 系统修复： 使用 chroot 进入受损系统进行修复操作。 简化依赖： 将服务依赖的文件与主系统隔离，便于管理和迁移。 chroot 实战：搭建模拟环境 以下是一个以 Postfix 调用 SASL 为例的 chroot 配置实战，帮助我们验证服务在隔离环境中的运行。 ...

Title: Using ssl_password_file in NGINX for SSL/TLS Private Key Management Introduction The ssl_password_file directive in NGINX specifies a file containing passwords used to unlock encrypted SSL/TLS private keys. When NGINX starts or reloads, it reads this file to load and decrypt the private key. Incorrect passwords in this file will prevent NGINX from starting or reloading successfully. Syntax Syntax: ssl_password_file file; Default: — Context: http, server This directive appeared in version 1.7.3. file: Specifies the path to the password file. Each line in the file should contain a single password. When loading a private key, NGINX will try the passwords in sequence. Default By default, the ssl_password_file directive is not enabled, and no password file is set. ...

ssl_password_file 是 NGINX 中的一个指令，用于指定一个包含密码的文件，这个文件用于提供 SSL/TLS 私钥的密码。该指令在 NGINX 启动时会读取该文件，并用于加载私钥文件时解锁加密的私钥。如果私钥是加密的，那么 NGINX 需要密码才能使用它，密码错误会导致nginx启动或者重新加载失败。 语法 Syntax: ssl_password_file file; Default: — Context: http, server This directive appeared in version 1.7.3. ``：指定包含密码的文件路径。这个文件应该包含一个用于解锁 SSL 私钥的密码。 指定一个包含密钥密码的文件，每个密码都位于单独的一行。在加载密钥时，密码将按顺序尝试。 默认值 默认情况下，ssl_password_file 指令不被启用，即没有设置密码文件。 使用场景 该指令通常在以下情况下使用： 1. 私钥加密：当生成 SSL/TLS 私钥时，如果你为私钥设置了密码保护，那么每次 NGINX 启动时，都需要提供密码才能加载私钥。 配置示例 生成四组自签名证书及私钥， 其中RSA算法两个， ECC算法两个，两组证书中一个带密码，一个不带密码。使用脚本生成 #!/bin/bash # Set directory variables CERTS_DIR="/etc/nginx/ssl" # Create the certificate directory if it doesn't exist mkdir -p $CERTS_DIR # Set passwords for different key types PASSWORD_RSA_WITH="password123" PASSWORD_ECC_WITH="password789" # Create password files for multiple certificates echo $PASSWORD_RSA_WITH > "$CERTS_DIR/rsa_password.txt" chmod 600 "$CERTS_DIR/rsa_password.txt" echo $PASSWORD_ECC_WITH > "$CERTS_DIR/ecc_password.txt" chmod 600 "$CERTS_DIR/ecc_password.txt" cat "$CERTS_DIR/rsa_password.txt" "$CERTS_DIR/ecc_password.txt" > "$CERTS_DIR/password_file.txt" # Set certificate information COUNTRY="CN" STATE="BEIJING" LOCALITY="BEIJING" ORG="test" ORG_UNIT="test-unit" EMAIL="email@example.com" # Generate RSA private key with password openssl genpkey -algorithm RSA -aes256 -out "$CERTS_DIR/rsa_private_key_with_password.pem" -pass pass:$PASSWORD_RSA_WITH echo "Generated RSA private key with password: rsa_private_key_with_password.pem" # Generate RSA private key without password openssl genpkey -algorithm RSA -out "$CERTS_DIR/rsa_private_key_without_password.pem" echo "Generated RSA private key without password: rsa_private_key_without_password.pem" # Generate RSA Certificate Signing Request (CSR) with password, avoiding interactive input COMMON_NAME="example1.com" openssl req -new -key "$CERTS_DIR/rsa_private_key_with_password.pem" -out "$CERTS_DIR/rsa_csr_with_password.pem" \ -passin pass:$PASSWORD_RSA_WITH \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated RSA CSR with password: rsa_csr_with_password.pem" # Generate RSA CSR without password, avoiding interactive input COMMON_NAME="example2.com" openssl req -new -key "$CERTS_DIR/rsa_private_key_without_password.pem" -out "$CERTS_DIR/rsa_csr_without_password.pem" \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated RSA CSR without password: rsa_csr_without_password.pem" # Use the RSA private key to sign the certificate openssl x509 -req -in "$CERTS_DIR/rsa_csr_with_password.pem" -signkey "$CERTS_DIR/rsa_private_key_with_password.pem" -out "$CERTS_DIR/rsa_certificate_with_password.pem" -days 365 -passin pass:$PASSWORD_RSA_WITH openssl x509 -req -in "$CERTS_DIR/rsa_csr_without_password.pem" -signkey "$CERTS_DIR/rsa_private_key_without_password.pem" -out "$CERTS_DIR/rsa_certificate_without_password.pem" -days 365 echo "Generated RSA certificates" # Generate ECC private key with password openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -aes256 -out "$CERTS_DIR/ecc_private_key_with_password.pem" -pass pass:$PASSWORD_ECC_WITH echo "Generated ECC private key with password: ecc_private_key_with_password.pem" # Generate ECC private key without password openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out "$CERTS_DIR/ecc_private_key_without_password.pem" echo "Generated ECC private key without password: ecc_private_key_without_password.pem" # Generate ECC CSR with password, avoiding interactive input COMMON_NAME="example3.com" openssl req -new -key "$CERTS_DIR/ecc_private_key_with_password.pem" -out "$CERTS_DIR/ecc_csr_with_password.pem" \ -passin pass:$PASSWORD_ECC_WITH \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated ECC CSR with password: ecc_csr_with_password.pem" # Generate ECC CSR without password, avoiding interactive input COMMON_NAME="example4.com" openssl req -new -key "$CERTS_DIR/ecc_private_key_without_password.pem" -out "$CERTS_DIR/ecc_csr_without_password.pem" \ -subj "/C=$COUNTRY/ST=$STATE/L=$LOCALITY/O=$ORG/OU=$ORG_UNIT/CN=$COMMON_NAME/emailAddress=$EMAIL" echo "Generated ECC CSR without password: ecc_csr_without_password.pem" # Use the ECC private key to sign the certificate openssl x509 -req -in "$CERTS_DIR/ecc_csr_with_password.pem" -signkey "$CERTS_DIR/ecc_private_key_with_password.pem" -out "$CERTS_DIR/ecc_certificate_with_password.pem" -days 365 -passin pass:$PASSWORD_ECC_WITH openssl x509 -req -in "$CERTS_DIR/ecc_csr_without_password.pem" -signkey "$CERTS_DIR/ecc_private_key_without_password.pem" -out "$CERTS_DIR/ecc_certificate_without_password.pem" -days 365 echo "Generated ECC certificates" # Print the generated file paths echo "RSA Certificate (with password): $CERTS_DIR/rsa_certificate_with_password.pem" echo "RSA Private Key (with password): $CERTS_DIR/rsa_private_key_with_password.pem" echo "RSA Certificate (without password): $CERTS_DIR/rsa_certificate_without_password.pem" echo "RSA Private Key (without password): $CERTS_DIR/rsa_private_key_without_password.pem" echo "ECC Certificate (with password): $CERTS_DIR/ecc_certificate_with_password.pem" echo "ECC Private Key (with password): $CERTS_DIR/ecc_private_key_with_password.pem" echo "ECC Certificate (without password): $CERTS_DIR/ecc_certificate_without_password.pem" echo "ECC Private Key (without password): $CERTS_DIR/ecc_private_key_without_password.pem" ssl_password_file 来指定该文件： ...

NGINX中收到HTTP请求大小相关的错误,以下典型错误及相关解决方案。 nginx 配置文件 nginx.conf user root; worker_processes 1; error_log logs/error.log debug; #pid logs/nginx.pid; events { worker_connections 1024; } http { #large_client_header_buffers 4 16k; server { listen 80; server_name localhost; location / { root /root/nginx-quic/html; index index.html index.htm; } } } 1. 请求头超长（HTTP 400/414） HTTP 400 (Bad Request)：请求头过大，导致无法解析。 HTTP 414 (URI Too Long)：请求行（URI 部分）过长。 模拟请求头超长 curl -v -H "$(head -c 8192 < /dev/zero | tr '\0' 'A'): value" http://localhost 此命令发送一个包含 8192 个字符的请求头字段, 返回结果 < HTTP/1.1 400 Bad Request < Server: nginx/1.25.4 < Date: Sat, 23 Nov 2024 13:26:23 GMT < Content-Type: text/html < Content-Length: 233 < Connection: close 检查 error.log，通常会看到类似以下错误： ...

Common NGINX HTTP Request Size Errors and Their Solutions Here is a sample nginx.conf configuration file: user root; worker_processes 1; error_log logs/error.log debug; #pid logs/nginx.pid; events { worker_connections 1024; } http { #large_client_header_buffers 4 16k; server { listen 80; server_name localhost; location / { root /root/nginx-quic/html; index index.html index.htm; } } } 1. Oversized Request Headers (HTTP 400/414) HTTP 400 (Bad Request): The request headers are too large and cannot be parsed. HTTP 414 (URI Too Long): The request line (URI) is excessively long. Simulating Oversized Request Headers You can use the following command to simulate a request with an overly large header: ...

shell中如果定义多行的字符串可以使用heredoc 先检查一下当前使用shell echo $0 -bash heredoc 是一种在 Shell 脚本、编程语言（例如 Bash、PHP、Ruby 等）中，用来定义多行字符串的方法。它可以使代码中的字符串定义更加清晰和可读，尤其适用于需要定义包含多行内容的文本块时。以下是 heredoc 的基本用法和一些示例。 Bash 中的 Heredoc 语法 在 Bash 中，heredoc 的语法如下： command <<EOF 内容... EOF command 表示你要将这些多行内容传递给的命令，例如 cat、echo 等。 &lt;&lt;EOF 表示开始使用 heredoc，其中 EOF 是一个标识符，用来定义多行文本的结束位置。你可以使用其他标识符来替代 EOF，例如 END，但开始和结束的标识符必须一致。 结束标识符必须单独一行，且通常没有前后的空格。 示例 1. 输出多行文本 你可以使用 heredoc 来输出多行文本： cat <<EOF 这是第一行 这是第二行 这是第三行 EOF 输出结果为： 这是第一行 这是第二行 这是第三行 2. 写入文件 你可以将 heredoc 的内容重定向到一个文件： cat < myfile.txt 这是要写入文件的内容 第二行 第三行 EOF 这会将文本块写入名为 myfile.txt 的文件中。 3. 结合命令 也可以将 heredoc 与其他命令结合使用，例如 while 循环： ...