公司网站怎样备案防恶意竞价点击软件

背景

在azure创建一个虚拟机vmtest1，如果无密码登录，azure会：

• 让你指定一个admin username, 帮你生成一个keypair, 不像aws一样可以选择rsa或者ed25519，azure只有rsa类型
• 帮你把pubkey 写入到vm中你指定的admin user 家目录下.ssh/authrozed_keys中
• portal上会让你下载保管好private key（因为公钥的信息可以用私钥导出，所以它就给你一个私钥文件，好懒），微软并不会保存这个key, 丢失了就需要重新创建哦
  

一般来说，你把这个私钥下载到本地，使用native ssh命令 确实可以直接登录vmtest1，打开win cmd 像这样：

PS：必须使用刚才跟keypair绑定的username@ip, 不带用户名会失败
ssh -i vmtest1_key.pem allen@172.188.73.105

问题

正常来说，这样就能连上管理了。但是，正经人谁用cmd当ssh 客户端啊，一般是xshell,或者crt，我这里用的crt 8.7.2就出现问题了，配置pubkey登录时遇到问题，记录如下：

问题一： 提示找不到pub key文件？

因为刚刚下载的只有私钥，确实是没有，因此，会话选项–>SSH2–>身份验证–>PublicKey–>属性 窗口中需要手动导出一个pub key文件，格式选择OpenSSH 或者standard 都行。保存文件名选择Identity.pub

问题二：生成了pub key，依然提示文件不匹配或者找不到文件？

crt 要求 keypair的文件名必须是Identity（私钥） + Identity.pub（公钥）， 还必须是在同一个文件夹下！！

问题三：文件名合格了，依然认证失败？

可能是客户端提供和服务端不匹配，导致ssh-rsa算法不在publickeyalgorithms中, 于是这个pubkey就不被接受，认证失败:

服务器ssh版本比较新，处于安全性考虑，已经移除了这ssh-rsa这种算法的pubkey：

allen@vmtest1:~$ ssh -V
OpenSSH_8.9p1 Ubuntu-3ubuntu0.7, OpenSSL 3.0.2 15 Mar 2022

使用crt尝试连接，从一个打开的会话查看server auth日志 会看到报错

`allen@vmtest1:~$ tail -f /var/log/auth.log
userauth_pubkey: key type ssh-rsa not in PubkeyAcceptedAlgorithms [preauth]

解决办法：

此时需要修改server的sshd配置 在sshd_config追加一行 然后重启服务：
PubkeyAcceptedAlgorithms +ssh-rsa

此时crt就能正常连接到vm：

那么，为什么使用cmd中的ssh -i 就不会出现这个 问题呢？服务端版本是固定的呢！为什么crt就要报错？

首先我本机win的ssh版本是：

C:\Users\x3>ssh -V
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2

通过- vvv仔细查看ssh的协商过程会发现：
关于各种Key交换，cipher交换的算法和格式，client proposal是这样的，host-key部分确实有列出ssh-rsa格式：

debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib

server proposal是这样的，新版本的openssh已经移除这个算法，host-key部分是看不到了：

debug2: peer server KEXINIT proposal debug2: KEX algorithms:
curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,sntrup761x25519-sha512@openssh.com,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,kex-strict-s-v00@openssh.com
debug2: host key algorithms:
rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 debug2:
ciphers ctos:
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc:
chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos:
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc:
umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com debug2: compression
stoc: none,zlib@openssh.com

首先，不管server中是否已经在authorized_keys中记录了client的pubkey文件，ssh -i的时候 都会重新发送一遍pubkey, 然后这里能看到最终协商用到的host-key算法为rsa-sha2-512：

debug1: Next authentication method: publickey
debug1: Trying private key: vmtest1_key.pem
debug3: sign_and_send_pubkey: RSA SHA256:e50MgUjmqqtDp6f+9R104fZTnqzNYCOumX76yH6ygwI
debug3: sign_and_send_pubkey: signing using rsa-sha2-512

所以 系统从指定的私钥文件中重新生成的pubkey文件发送到server后，不会报错算法不识别，因为是已经协商的结果！！

而CRT可能就是直接按照你指定的pubkey文件格式发送了吧…

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDI0GUvA2TIR0SKAr/Iefddipnzxs6tmR9uJgmbFIuvVbxqXOuka/KdyAIq5qGjjGXMTbEy1eEWpidNzSnc3jbh9JAjD5NBgNXP1YSC5El5AoTxZuLn+w8GO9K/pswrA5gXV+bXDVVb2GmNtjLjy1kdadvsBUJDnY5MVDPXMWBMJpJxqfWLXBEh2LUO7zORWyaIW1I7m31QHSVm9A/EqccmII+dG8YV1EOT8eHBLndAs+KXex4VBrSzN1yqz5uj4IKXnFLHDoO4Zl/cCW7UIeefbC4F4G5ureq45SjNqq2G9ggfplmVjg5nk5PAU/2pkEZNHBAJwCuSkpL34mPgwc42VHf74U/PuaMPn/U0XYZ1veJYImfF3mVumIMgEwfGKBrqArhOZyjy9smYh4REkE6ay9MwqY6Xd1bNAjSJbEBpZV3OPusvNbPeABMMqHiScvkUcBa7EHAhrT+KBDJkg65HiR22J2ih5tm6CUi+//CeVX1Kkl0uf0Q6tgUIrt8QV5U= “x3@Chaste”