如何为多个PHP-FPM容器构建单一的Nginx Docker镜像

在使用 Docker 容器来开发 PHP 微服务套件的过程中,作者遇到了容器数量过多的问题。

最近,我一直在使用 Docker 容器来开发 PHP 微服务套件。一个问题是 PHP 应用已经搭建,可以与 PHP-FPM 还有 Nginx(取代了简单的 Apche/PHP 环境)一起工作,因此每个 PHP 微服务需要两个容器(以及两个 Docker 镜像):一个 PHP-FPM 容器和一个 Nginx 容器。
这个应用运行了 6 个以上的服务,做个乘法就知道,在开发和生产之间会有约 30 个容器。于是我决定构建一个单独的 Nginx Docker 镜像,它可以使用 PHP-FPM 的主机名作为环境变量并运行单独的配置文件,而不用为每个容器构建单独的 Nginx 镜像。

未分类

在本文中,我介绍了自己从上图中的方法 1 到方法 2 的转换,最后采用的方案中采用了一种新的定制 Docker 镜像。该镜像的代码是开源的,如果读者碰到类似问题,可以提供给大家参考。

为什么用 Nginx?

Nginx 和 PHP-FPM 配合使用能使 PHP 应用的性能更好,但不好的地方在于,和 PHP Apache 镜像不同,PHP-FPM Docker 镜像默认不是和和 Nginx 绑定在一起的。如果需要通过 Nginx 容器和 PHP-FPM 连接,需要在 Nginx 配置里为该后端增加 DNS 记录。比如,如果名为 php-fpm-api 的 PHP-FPM 容器正在运行,Nginx 配置文件应该包含下面部分:

location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        # This line passes requests through to the PHP-FPM container
        fastcgi_pass php-fpm-api:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

如果只服务于单独的 Nginx 容器,Nginx 配置中容器名字写死还可以接受,但如上所述,需要允许多个 Nginx 容器,每个对应于一个 PHP 服务。创建一个新的 Nginx 镜像(以后需要进行维护和升级)会有些痛苦,即使管理一批不同的数据卷,仅仅改变变量名看起来也有很多工作。

第一种方案: 使用 Docker 文档中的方法

最初,我认为这会很简单。Docker 文档中有少许的几个章节讨论如何使用 envsubst 来完成该工作,但不幸的是,在我的 Nginx 配置文件中,这种方法不奏效。

vhosts.conf

server {
    listen 80;
    index index.php index.html;
    root /var/www/public;
    client_max_body_size 32M;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass ${NGINX_HOST}:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

该vhosts.conf文件使用了 Nginx 内置变量,因此当依照文档运行 Docker 命令 (/bin/bash -c “envsubst < /etc/nginx/conf.d/mysite.template > /etc/nginx/conf.d/default.conf && nginx -g ‘daemon off;’”) 时,得到错误提示$uri和$fastcgi_script_name没有定义。这些变量通常通过 Nginx 传入,因此不能简单的识别出他们是什么并传给自身,而且这样会影响容器的动态配置。

使用另一个 Docker 镜像,差点成功

接下来,我开始研究不同的 Nginx 镜像。找到的有两个,但它们都在随后的几年中都没有任何更新。我开始使用 martin/nginx,试图找到可以工作的原型。

Martin 的镜像和其它镜像有点不一样,因为它要求特定的文件夹结构。在 root 下增加Dockerfile:

FROM martin/nginx

接下来,我添加了一个app/空目录和conf/目录,conf/目录下只有一个文件
vhosts.conf:

server {
    listen 80;
    index index.php index.html;
    root /var/www/public;
    client_max_body_size 32M;
    location / {
        try_files $uri /index.php?$args;
    }
    location ~ .php$ {
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass $ENV{"NGINX_HOST"}:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

这个文件和之前的配置文件几乎一样,除了有一行的改动:
fastcgi_pass $ENV{“NGINX_HOST”}:9000;。现在想要启动带命名为 php-fpm-api 的 PHP 容器的 Nginx 容器,就可以构建一个新的镜像,让它在以下环境变量下运行:

docker build -t shiphp/nginx-env:test .
docker run -it --rm -e NGINX_HOST=php-fpm-api shiphp/nginx-env:test

它可以正常工作了。但是,这种方法有两个困扰的地方:
正在使用的基础镜像已经有两年了。这会引入安全和性能风险。
有个空的/app目录看起来并不必需,因为文件会被存储在一个不同的目录中。

最终解决方案

我认为作为定制解决方案,从 Martin 镜像开始比较好,因此我给项目建了分叉,创建了新的 Nginx 基础镜像并修复了上述两个问题。现在,如果要在 Nginx 容器中允许动态命名的后端,可以参照:

# 从 Docker Hub 得到最新版本
docker pull shiphp/nginx-env:latest
# 运行名为"php-fpm-api"的 PHP 容器 
docker run --name php-fpm-api -v $(pwd):/var/www php:fpm
# 允许链接到 PHP-FPM 容器的 NGinx 容器
docker run --link php-fpm-api -e NGINX_HOST=php-fpm-api shiphp/nginx-env

如果想增加自己的文件或 Nginx 配置文件,来定制镜像,用Dockerfile来扩展它就可以:

FROM shiphp/nginx-env
ONBUILD ADD <PATH_TO_YOUR_CONFIGS> /etc/nginx/conf.d/
...

现在所有的 PHP-FPM 容器都能使用单个Docker镜像中自己的实例,这样在升级 Nginx,改变权限或做某些调整时,就变得非常轻松了。

所有的代码都在 Github 上,如果你看到任何问题或有改进建议,可以直接创建 issue。

GitHub 项目链接:https://github.com/shiphp/nginx-env

nginx 和 frp共用80端口

之前用frp做内网穿透,把内网的服务器开放到外网。

如果是http服务的话,80端口的做法是使用二级域名xxx做个A记录指一台没有nginx 之类的服务器IP,然后用浏览器打开xxx.example.com就打开了。其他端口是在frpc.ini里指定的,就加个端口号如xxx.example.com:1234就打开了,这种情况用于外网服务器已经有nginx在运行占用了80端口, 这时如果不想用端口号来打开,就要做三级域名解析,同时nginx做反向代理,把这个1234端口代理到80.

其实只要给 nginx 增加一个简单的配置,就可以将某个域名的流量转发给 frp 了,还可以通过泛解析来映射不同的网站。

配置 nginx:

server {
    listen 80;
    server_name *.frp.example.com;
    location / {
        proxy_pass http://127.0.0.1:8081;
        proxy_set_header    Host            $host:80;
        proxy_set_header    X-Real-IP       $remote_addr;
        proxy_set_header    X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_hide_header   X-Powered-By;
    }
}

上面这段写入/etc/nginx/sites-avaliable/default的最后面,监听*.frp.example.com, 并转发给127.0.0.8081, 接下来只要将frp默认监听 80 端口改成 8081 端口就好了.

配置 frp 服务端:

[common]
bind_port = 8787
vhost_http_port = 8081
token = passwd
max_pool_count = 100
subdomain_host = frp.example.com

[xxx]
type = http
subdomain = xxx

重点在于将 vhost_http_port 设为 8081, 还可以在common下加上dashboard相关的端口,用户,密码等信息。

配置 frp 客户端:

[common]
server_addr = exampel.com 
server_port = 8787 
token = passwd
login_fail_exit = false 

[xxx]
type = http
local_port = 80
subdomain = xxx

域名设置:

1, 增加二级域名frp的A解析,到外网服务器IP.

  1. 增加三级域名泛解析*.frp的CNAME解析,到frp.example.com.

这时要做完这2个域名解析就可以用xxx.frp.example.com访问了。

参考:http://www.miss.cat/frp-use-80-port-with-nginx/

https://blog.csdn.net/qq_36560161/article/details/79646523

如果是ssh,frpc如下面配置的话,还是一样的,跟http上面讲的东西没有关系:

[common]
server_addr = example.com 
server_port = 8787 
token = passwd
login_fail_exit = false 

[ssh-xxx]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 5000

还是这样登录:

ssh [email protected] -p5000

WordPress禁用自动保存草稿去除文章修订功能

下面的方法需要修改源文件所以在打开每一个文件之前,记得一定要先做好备份!

禁用文章修订历史版本

1.打开 wp-config.php 文件
2.在 $table_prefix = ’wp_’; 前面添加下面的两行代码:

define('WP_POST_REVISIONS', false);//禁用历史修订版本
define('AUTOSAVE_INTERVAL', false);//自动保存时间设置为一天

如下:

未分类

禁用自动保存功能

1.打开 wp-admin/post.php 文件,搜索 if ( ’attachment’ !== $post_type ) ,找到以下代码 150-151行

if ( 'attachment' !== $post_type )
wp_enqueue_script('autosave');

将这两行用注释符号//注释即可!如下:

未分类

2.打开 wp-admin/post-new.php 文件,搜索 wp_enqueue_script( ’autosave’ ); (69行),在代码前面加//将其注释或删除

未分类

禁用自动草稿功能

打开 wp-adminincludespost.php 文件,搜索 if ( $create_in_db ) { 找到以下代码 597行

$post_id = wp_insert_post( array( 'post_title' => __( 'Auto Draft' ), 'post_type' => 
$post_type, 'post_status' => 'auto-draft' ) ); $post = get_post( $post_id );

修改为:

global $current_user,$wpdb; $post = $wpdb->get_row( "SELECT * FROM $wpdb->posts WHERE post_status = 'auto-draft' AND post_type = '$post_type' AND post_author = $current_user->ID ORDER BY ID ASC LIMIT 1" ); if (!($post) ) { $post_id = wp_insert_post( array( 'post_title' => __( 'Auto Draft' ), 'post_type' => $post_type, 'post_status' => 'auto-draft' ) ); $post = get_post( $post_id ); }

如下:

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码

导语:WordPress是网络上最受欢迎的CMS。在这篇文章中,我们将讲述在WordPress内核中引入一个经认证的任意文件删除漏洞,这个漏洞可能会导致攻击者执行任意代码。

未分类

简介

WordPress是目前网络上最受欢迎的CMS。根据w3tech的资料显示,约有30%的网站都在使用它1。这种广泛的采用,也使其成为了网络犯罪分子非常感兴趣的一个目标。在这篇文章中,我们将讲述在WordPress内核中引入一个经认证的任意文件删除漏洞,这个漏洞可能会导致攻击者执行任意代码。在7个月前,我们向WordPress安全团队报告了这个漏洞,但至今依然没有得到修复。由于经过了这么长时间,WordPress官方都没有发布任何补丁或具体修复计划,所以我们决定公开这个事件。

受影响的版本

截止到本篇文章发送时,还没有补丁可防止此漏洞的使用。任何WordPress版本(包括当前的4.9.6版本),都容易受到该漏洞的影响。

如果要利用该漏洞,攻击者需要事先获得编辑和删除媒体文件的权限。因此,该漏洞可以通过对与作者权限相同的用户来提升权限,或者通过其他漏洞的错误配置来利用。

攻击带来的影响

利用此漏洞,使攻击者能够删除WordPress安装的任何文件(+ PHP服务器上的任何其他文件,PHP进程用户具有适当的删除权限)。除了删除整个WordPress安装文件对系统的影响(如果没有当前备份可用,会导致灾难性后果),攻击者可以利用任意文件删除功能绕过一些安全措施,并在Web服务器上执行任意代码。更确切地说,可以删除以下文件:

  • .htaccess:一般来说,删除此文件不会有不安全的影响。但是,在某些情况下,.htaccess文件包含与安全相关的约束(例如,对某些文件夹的访问限制)。因此,删除此文件将会禁用这些安全限制。

  • index.php文件:通常情况下,将空的index.php文件放置到目录中,以防止Web服务器无法执行的情况下的目录列表。如果删除这些文件则将为攻击者提供一份列表,列出受此措施保护的目录中的所有文件。

  • wp-config.php:删除这个WordPress安装文件,会在下次访问该网站时触发WordPress安装过程。这是因为wp-config.php包含数据库凭证,如果没有它,WordPress的将认为它尚未安装。攻击者可以删除该文件,使用管理员帐户选择的凭据进行安装过程,最后在服务器上执行任意代码。

如需观看视频,请点击此处查看原文https://blog.ripstech.com/2018/wordpress-file-delete-to-code-execution/

技术细节

当用户输入传递文件删除功能时,会发生任意文件删除漏洞。在PHP中,当unlink()调用该函数,并且用户输入可能会影响部分或整个参数$filename(表示要删除的文件的路径)时,会发生这种情况,而WordPress不会进行适当的处理。

在该wp-includes/post.php文件中找到了在WordPress Core中使这个漏洞成为可能的代码部分:

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码
在wp_delete_attachement()上面显示的功能中,$meta[‘thumb’]呼叫中使用的内容unlink()未经过任何处理。这段代码的目的是在删除图像的同时删除图像的缩略图。在WordPress中通过媒体管理器上传的图像被表示为附属类型的帖子。该值$meta[‘thumb’]从数据库中检索,并保存为表示图像的文章的自定义字段2。因此,在数据库检索和关键函数调用之间使用unlink(),表示缩略图文件名的值不经过任何清理或检查。如果该值在保存到数据库之前也没有经过任何安全措施,我们将在下一个代码列表中看到情况,我们有一个二阶任意文件删除漏洞。

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码
此代码片段/wp-admin/post.php代表了附件中属于附件的缩略图的文件名如何保存到数据库中。在从保存在$_POST[‘thumb’]数据库中的用户输入中检索和保存到数据库wp_update_attachment_metadata()之间没有任何安全措施,以确保该值代表正在编辑的附件的缩略图。$_POST[‘thumb’]对于任何文件的路径,这个值可以保存到WordPress上传目录的相对路径中,当附件被删除时,该文件将被删除,如第一列表中所示。

临时修复程序

在编写此篇文章时,此漏洞在WordPress内核中仍未被修复。正因为这样,我们开发了一个临时修复程序。通过将修复程序添加到functions.php当前活动的主题/子主题文件中,可以将修复程序集成到现有的WordPress安装中。

未分类

WordPress内核中一个任意文件删除漏洞,可导致攻击者执行任意代码
所有提供的修复程序都会挂接到wp_update_attachement_metadata()调用中,并确保为元值提供的数据thumb不包含任何使路径成为可能的部分。因此,不能删除与安全相关的任何文件。

我们所提供的修复方案属于临时修复,以防止攻击。我们无法监督WordPress插件的所有可能的向后兼容性问题,因此建议您谨慎的对WordPress文件进行任何修改。

时间线

未分类

总结

在这文章中,我们介绍了WordPress内核中引入了一个任意文件删除漏洞,它允许任何具有作者权限的用户完全接管WordPress网站,并在服务器上执行任意代码。该漏洞去年已报告给WordPress安全团队,但在编写本文时仍然没有作任何修复。

为了提高对此漏洞的认识,我们决定发布一些细节和修复程序。使用我们的安全分析解决方案可以轻松发现漏洞,我们确信这个问题已经被许多研究人员所了解。尽管用户帐户的需求阻止了任意WordPress站点的大规模开发,但共享多个用户帐户的WordPress站点应该应用此修复程序。

让一个端口同时做两件事:http/https和ssh

相信很多人都在YY:能不能让80端口分析连接协议,如果是http协议就让服务器交给http服务程序(如Apache、Nginx等)处理,如果是ssh协议就交给ssh服务程序(如OpenSSH Server)处理呢?

答案显然是有的。

首先,配置http服务程序监听8080端口或者让https服务监听8443端口,配置ssh服务程序监听22端口。具体不再赘述,如果这都不懂就不用往下看了,因为肯定会搞不定的。

然后,安装一个叫haproxy的强大工具。步骤如下。

下载源代码:

wget http://haproxy.1wt.eu/download/1.4/src/haproxy-1.4.16.tar.gz

查看当前内核版本:

uname -r

然后进入目录编译安装:

cd haproxy-1.4.16
make TARGET=linux26 PREFIX=/usr/local/blog.creke.net/haproxy
make install PREFIX=/usr/local/blog.creke.net/haproxy

其中,第二行的“TARGET”参数要和内核版本一致。第二、三行的“PREFIX”是安装位置。

最后,配置haproxy。

如果要监听80端口,检测到http协议就转发给8080端口使用HTTP,否则转发给22端口使用ssh。配置如下:

#By http://blog.creke.net/
global 
    maxconn 5120  
    chroot /usr/local/blog.creke.net/haproxy   
    daemon 
    quiet 
    nbproc 2 
    pidfile /usr/local/blog.creke.net/haproxy/haproxy.pid
defaults 
    timeout connect 5s 
    timeout client 50s 
    timeout server 20s
listen http 
    bind :80 
    timeout client 1h 
    tcp-request inspect-delay 2s 
    acl is_http req_proto_http 
    tcp-request content accept if is_http 
    server server-http :8080 
    use_backend ssh if !is_http
backend ssh 
    mode tcp 
    timeout server 1h 
    server server-ssh :22

如果还有监听443端口,检测到https协议就转发到8443端口使用HTTPS,否则转发给22端口使用ssh。则配置如下:

global 
    maxconn 5120  
    chroot /usr/local/blog.creke.net/haproxy   
    daemon 
    quiet 
    nbproc 2 
    pidfile /usr/local/blog.creke.net/haproxy/haproxy.pid
defaults 
    timeout connect 5s 
    timeout client 50s 
    timeout server 20s
listen https 
    bind :443 
    timeout client 1h 
    tcp-request inspect-delay 2s 
    acl is_ssl req_ssl_ver 2:3.1 
    tcp-request content accept if is_ssl 
    server server-https :8443 
    use_backend ssh if !is_ssl
backend ssh 
    mode tcp 
    timeout server 1h 
    server server-ssh :22

把内容保存为“/usr/local/blog.creke.net/haproxy/etc/haproxy.conf”,执行命令:

/usr/local/blog.creke.net/haproxy/sbin/haproxy -f /usr/local/blog.creke.net/haproxy/etc/haproxy.conf

即可运行。

好了,大家应该可以举一反三,起码也可以依葫芦画瓢吧。

centos 7下SSH的一些安全配置

0、说明

0.1、实验环境系统为Centos 7.4系统,最小化安装后未做任何配置

1、修改SSH默认连接端口

1.1、确保SELinux处于关闭状态

[root@imzcy ~]# setenforce 0
[root@imzcy ~]# sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

1.2、编辑sshd_config配置文件,修改默认端口(17行左右)。并重启sshd服务使配置生效

[root@imzcy ~]# grep ^Port /etc/ssh/sshd_config 
Port 10022
[root@imzcy ~]# systemctl restart sshd

1.3、firewalld防火墙添加规则,放行tcp/10022端口

#添加防火墙规则
[root@imzcy ~]# firewall-cmd --permanent --zone=public --add-port=10022/tcp
[root@imzcy ~]# firewall-cmd --reload

#确认配置
[root@imzcy ~]# firewall-cmd --list-all |grep 10022
  ports: 10022/tcp

这时候就可以使用10022端口连接ssh服务器了。
可能遇到的问题:

如果修改完ssh端口号,重启sshd服务报错,然后注释掉之前的更改就能正常重启,请使用getenforce命令检查下selinux状态是否为关闭

2、禁止root用户远程登录

#2.1、修改sshd_config配置文件(38行左右)
[root@imzcy ~]# grep ^PermitRootLogin /etc/ssh/sshd_config 
PermitRootLogin no
[root@imzcy ~]# 

#2.2、重启sshd服务,使配置立即生效
[root@imzcy ~]# systemctl restart sshd

3、限制ssh访问服务器的源IP

#编辑hosts.allow配置文件,追加一行内容
[root@imzcy ~]# echo "sshd:192.168.43.226:allow" >>/etc/hosts.allow

#编辑hosts.deny配置文件,追加一行内容
[root@imzcy ~]# echo "sshd:ALL" >>/etc/hosts.deny

这里只写了一种方法,还可以通过修改sshd_config配置文件来限制源IP,也可以使用firewalld来限制源IP

4、限制ssh访问服务器的用户名

#修改sshd_config配置文件,允许zcy用户ssh访问服务器(以空格分开用户;添加完允许,默认拒绝其他所有用户)
[root@imzcy ~]# echo "AllowUsers zcy" >>/etc/ssh/sshd_config

#重启sshd服务,使配置立即生效
[root@imzcy ~]# systemctl restart sshd

5、修改telnet ssh端口时显示的版本号

#5.1、查看sshd位置
[root@imzcy ~]# whereis sshd
sshd: /usr/sbin/sshd /usr/share/man/man8/sshd.8.gz

#5.2、查看SSH版本
[root@imzcy ~]# ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips  26 Jan 2017

#5.3、查看sshd程序关于版本的信息
[root@imzcy ~]# strings /usr/sbin/sshd |grep OpenSSH_7.4
OpenSSH_7.4p1-RHEL7-7.4p1-11
OpenSSH_7.4
OpenSSH_7.4p1

#5.4、使用sed替换版本(记得一定要先备份下)
[root@imzcy ~]# cp -p /usr/sbin/sshd ./
[root@imzcy ~]# sed -i 's/OpenSSH_7.4/OpenSSH_2.3/g' /usr/sbin/sshd

#5.5、重启下sshd服务,没有报错即可
[root@imzcy ~]# systemctl restart sshd

再使用telnet连接ssh端口,显示的版本则为:SSH-2.0-OpenSSH_2.3

openwrt上用cifs挂载samba共享文件夹

用cifs挂载的时候不知道什么原因一直提示错误:

mount error(22): Invalid argument

花了一天时间找google,终于找到个方法,在后面加参数 vers=1.0 什么原理我也不知道,反正能行就好。

mount.cifs //192.168.2.1/op/1 /mnt/sda1/123 -o username=root,password=root,rw,vers=1.0

Tomcat禁用端口方法

tomcat默认启用端口解释:

  • 8005,tomcat关闭端口。
  • 8080,tomcat页面http端口。通常我们会修改为80
  • 8009,tomcat-AJP代理端口,通常做负载均衡用

多套tomcat防端口冲突方法:

1、修改conf/server.xml中的三个端口:8005,8080,8009,分别重置为新端口。这个感觉操作起来有些繁琐,

2、建议tomcat仅使用单个 http 端口。

2-1、禁用关闭端口

将 Server 元素的 port 属性设置为 -1,这将禁用 Tomcat 关闭端口。
我们强制tomcat不使用关闭端口,通过使用“kill -9 PID”命令来停止任何独立应用程序实例。
只需要将tomcat/conf/server.xml中的:

<Server port="8005" shutdown="SHUTDOWN"> 

修改为

<Server port="-1" command="SHUTDOWN"> 

2-2、禁用AJP
应通过注释掉tomcat/conf/server.xml中显示的节来禁用 AJP 连接器,以确保我们不会遇到端口冲突。

    <!-- Define an AJP 1.3 Connector on port 8009 --> 
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 

修改为:

    <!-- Define an AJP 1.3 Connector on port 8009 
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /> 
    --> 

2-3、修改http端口为80

    <Connector port="80" protocol="org.apache.coyote.http11.Http11NioProtocol"  
               connectionTimeout="20000"  
               redirectPort="8443" maxThreads="150"/> 

记一次SSH配置相关问题

今天新租了一VPS,在解决了IP被屏蔽等问题后,着手解决使用XShell连接SSH时存在的问题。如图:

未分类

同时连接速度也肉眼可见地慢。。。慢。。慢。

于是百度、Google 说是安装不完全,于是就安装

yum -y install xorg-x11-xauth

但是仍然有问题,报出这样的问题

/usr/bin/xauth: file /root/.Xauthority does not exist

最终把ssh配置的AllowAgentForwarding也改为yes就OK了(去掉注释)
前提是X11Forwarding yes这一条配置也要yes,不过默认应该都是的
我ssh的配置文件路径/etc/ssh/sshd_config
至此问题就完美解决了。

WordPress一次性搞定ssl全局设置以及潜在问题解决

首先按照自己的项目运行服务器把证书安装好,干货君以腾讯云为例:证书安装指引 – SSL 证书 – 文档平台 – 腾讯云文档平台 – 腾讯云。

干货君使用nginx反向代理,apache作为项目运行服务器为例,修改nginx/conf文件夹下面的nginx.conf(将下方代码块添加到文件中或把文件中443代码块按此方式设置)。

server {
listen 443;
server_name www.nrgh.org; #填写绑定证书的域名
ssl on;
ssl_certificate 1_www.nrgh.org_bundle.crt;
ssl_certificate_key 2_www.nrgh.org.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; #按照这个协议配置
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;#按照这个套件配置
ssl_prefer_server_ciphers on;
location / {
#项目路径,或反向代理的代码块
proxy_pass http://nrgh;
} 
}

未分类

上方搞定在nginx.conf中加入下面这个代码块,你要负载均衡(集群使用)也是在这个代码块中搞

upstream www{
#下方写要代理的ip和端口号,下面ip是乱写的,真实的已隐去
server 111.111.205.11:56;
}

未分类

server {
listen 80;
server_name http://www.nrgh.org
if ($scheme = http ) {
#http请求转换为https
return 301 https://$server_name$request_uri;
}
#即所有请求都到这里去找分配
location / {
#全局实现80进来的请求,重定向为https了
proxy_pass http://www;
#rewrite ^/(.*) https://$server_name/$1 permanent;
}
}

上面都配置之后,运行 nginx -t 并重启nginx试试效果

接下来说下会出现的问题:

1、上面都搞定之后,wordpress网站可能出现css和js还是走http请求,文章链接走https请求,这时候需要你把wordpress的媒体文件绝对路径替换相对路径,方法如下:

2、wordpress/wp-admin 后台进不去,登录无反应;

3、百度找了很多解决方法,却依然没有解决,甚至搞的连网站都打不开了;

4、等等。。。

一、系统文件修改

路径:网站根目录wp-includesfunctions.php
找到代码 require( ABSPATH . WPINC . ‘/option.php’ );
在下方添加:

add_filter('script_loader_src', 'agnostic_script_loader_src', 20,2); function agnostic_script_loader_src($src, $handle) { return preg_replace('/^(http|https):/', '', $src); } add_filter('style_loader_src', 'agnostic_style_loader_src', 20,2); function agnostic_style_loader_src($src, $handle) { return preg_replace('/^(http|https):/', '', $src); }

二、后台文件修改

路径:网站根目录wp-config.php
找到代码:

*
* @package WordPress
*/

在下方添加如下代码:

$_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_LOGIN', true);
define('FORCE_SSL_ADMIN', true);

三、安装插件

完成以上两步操作后,可以正常访问https开头的网站和后台,
下载这个叫“really-simple-ssl”的WordPress插件:

Really Simple SSL

登录后台安装此插件。

至此,真正意义上解决wordpress全站开启https的ssl证书问题。