标签： linux

重装了服务器系统，ssh证书更换，导致连不上服务器

今天重装了一台服务器，由debian改为ubuntu，使用阿里云重新绑定了密钥对，导致服务器连接失败。错误信息如下：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
……
Host key verification failed.

这个报错信息说明 服务器的主机密钥（Host Key）发生了变化，SSH 客户端发现和之前保存的不一致，所以拒绝连接。常见原因有：

  1. 服务器重装过系统，SSH 的 host key 变了。
  2. 更换了 IP 或 DNS 指向，连接到的机器其实不是原来的。
  3. 安全风险：如果不是你自己操作导致的变动，有可能存在中间人攻击（MITM）。

解决办法

如果你确认这是自己的服务器（比如你刚刚重装了系统或者更换了 SSH 配置），可以安全地删除旧的 key 再重新连接。

执行命令：

ssh-keygen -R server-ip

注意把server-ip改为你的服务器ip地址。这个命令是从~/.ssh/known_hosts文件中删除之前的连接记录，也可以直接编辑这个文件删除。

然后再次连接，会提示你保存新的主机指纹，输入 yes 即可。

如果提示Permissions 0644 for ....... are too open.这是证书文件的权限太大了，SSH 要求私钥文件必须 仅自己可读写，不能被其他用户访问。

执行下面的命令，修改私钥文件权限（只允许自己读写）：

chmod 600 /Users/wujie/.ssh/aliyun99.pem

注意改为你自己的密钥路径，最后再次连接应该就可以了。

服务器生成登陆密钥证书

在你的电脑上执行一下命令：

ssh-keygen -t rsa -b 4096 -C "bandwagonhost_dc3"

ssh-copy-id -i ~/.ssh/bandwagonhost_dc3.pub -p 22  server-user@server-ip

如果默认端口不是22，需要调整为响应的端口号。

如果本地的私钥丢失了，可以再次执行该命令，重新生成。

上述命令在 Mac 上验证通过，Windows 有待验证。

Supervisor部署ASP.NET core配置文件

在部署asp.net core的应用程序时，为防止进程退出，可以使用supervisor来守护asp.net core应用的进程，对于一个asp.net core应用supervisor配置如下，可以作为模板修改使用。

[program:pcsweb]
directory=/www/pcsweb
command=dotnet /www/pcsweb/YiSha.Admin.Web.dll
autostart=true
autorestart=true
stdout_logfile=/var/log/pcsweb_stdout.log
stderr_logfile=/var/log/pcsweb_stderr.log
startsecs=5
startretries=3
stopasgroup=true
killasgroup=true

Supervisor常用命令

supervisor常用命令，记录备忘。

supervisorctl   status              查看状态
supervisorctl   reload              重新载入配置文件
supervisorctl   start all/ftp     启动所有/指定的程序进程
supervisorctl   stop all/frp      关闭所有/指定的程序进程 

supervisorctl   restart pcsweb  重启进程

重启supervisor
systemctl restart supervisord

Supervisor 部署Django网站的配置

和asp.net core应用类似，django也是需要守护进程来守护的，配置如下：

[program:django-python]
#项目目录
direct=/var/www/www.example.com
#启动进程命令
command=/bin/bash -c "python3 /var/www/www.example.com/manage.py runserver 127.0.0.1:8080"
#是否自动启动
autostart=true
#是否自动重启
autorestart=true
stdout_logfile=/var/log/django_stdout.log
stderr_logfile=/var/log/django_stderr.log
user=root
stopsignal=TERM
startsecs=5
startretries=3
stopasgroup=true
killasgroup=true

Linux历险记

今天我犯了个大错，我在服务器上的htdocs目录下使用了 rm -rf * ，造成所有网站文件全没有了。犯这个错误的原因是：我以为当前的操作目录是网站目录。

当按下回车键后就傻了，愣了几秒钟。赶紧到网上找恢复方法，显示用debugfs试了下，发现只能一个文件一个文件的恢复（或许可以恢复目录，我没查到），不可行。继续插，又找到了extundelete，这个可以恢复目录，使用命令如下：

extundelete  /dev/vda1 --restore-directory /web/httpd/htdocs

/dev/vad1是用命令df -h找出来的（看第一列）。

这个倒是可以恢复，可能由于我extundelete是的误删了以后才装的，造成覆盖了磁盘，所以博客网站的文件没能恢复全。其他几个没用的网站倒是恢复了。

“算了，反正数据库还在，重新下载一个WordPress”，心里这么想着。于是备份了数据库，开始全新安装。神奇的是，安装好后，数据还在！！这说明WordPress做了检测，如果数据存在，就不覆盖。然后安装代码高亮插件。Ok，到这里，一切如初。

以后使用rm要考虑好！！！