ssh key 一模一样的设置，另一个就不能 登录是什么原因？

[selfcreditgiving]

要用 user1 用户 ssh 登录两台服务器。

两个服务器，拷贝了相同的公钥：
/home/user1/.ssh/id_rsa.pub
和 /home/user1/.ssh/authorized_keys （ id_rsa.pub 拷进来的）
两个文件的权限都是 700

/home/user1 文件夹的权限是 600

id_rsa.pub 、authorized_keys 、/home/user1 的所属用户和所属组都是 user1

/etc/ssh/sshd_config 设置的也是一模一样的， 也重新启动了 sshd service 。

为什么一台可以登录，一台就登录不了呢？
提示这个错误：

Permission denied (publickey).

每次都被这种东西卡住了，

/etc/ssh/sshd_config 配置都是这样的：

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation no

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin yes
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no                                                                                  

[xiaowei0823]

ssh -vvv 看一看呢

[Osk]

看看服务端的 sshd 日志. 里面也许有更有用的信息.

[selfcreditgiving]

@Osk ubuntu 的 sshd 日志 是 lastb 嘛？（是一个 ubuntu 的 docker 容器，会不会被精简了就没有日志了）
而且 lastb 命令提示 没有 /var/log/btmp 文件。 （就是因为这个文件我才要设置 ssh 密钥登录的，一直被暴力破解，一个服务器上大概有十几个 ubuntu 容器，每个容器的 btmp 文件 都有 2 ～ 4G ！）
@xiaowei0823 ssh -v 是 version 嘛， 没有这个 option 提示

[xiaowei0823]

使用 ssh -vvv 登录服务器的时候会打印详细日志，你两边对比一下看看无法登录的那台服务器卡在哪里了？

[ynyounuo]

@selfcreditgiving
-v
Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3.

看看 -vvv 应该能很快排查出来

[selfcreditgiving]

@xiaowei0823 @ynyounuo 多谢

[Osk]

如果是容器, 日志大概不会是 journalctl 来看.

尝试 grep -r sshd /var/log

[selfcreditgiving]

服务器 B （失败）

服务器 A （成功）

@xiaowei0823 @ynyounuo 请问服务器 B 为什么会找不到 rsa 的 key 呢 ，要去找什么 dsa_key ，都是在我同一个笔记本上操作的

[selfcreditgiving]

十几个容器，加起来 login fail 日志有 40G 了，云盘本来也就 100G 。 真没想到还有这么多的机器人来扫描

[Osk]

看起来是服务端拒绝了 rsa 的那个公钥, 所以 ssh 客户端这边会继续尝试 dsa, ecdsa ed25519 这几个 key 能否登录, 但那几个 key 都不存在.
而拒绝的原因需要看 b 服务器的 sshd 日志.

另外, 用公钥登录还是不能彻底杜绝扫描, 每次尝试还是有日志的吧, 要配合 faild2ban, sshguard 等才能挡一下.

[dingwen07]

看看 openssh 版本？一般来说能到这也不会有问题
还得看服务器上的日志

[HXM]

可以尝试暂时性的把 sshd_config 里 StrictModes 从 yes 改成 no 看看能不能登录，如果这样可以登录的话那就是文件权限问题

参考来源 https://web.archive.org/web/20140327182105/http://www.openssh.org/faq.html#3.14

[ynyounuo]

估计还是你 server B 上 .ssh/ 的文件夹权限问题，看看是不是 700

[selfcreditgiving]

@HXM @dingwen07 @ynyounuo 好的，我明天再试下看看。

@Osk 公钥还是会爆日志嘛，linux 开源世界能不能对程序员简单，友好一点呢，，， 来个开箱即用的多好啊。
不是专门的运维，有没有最少配置的最佳实践呢。 如果说装 vpn 能不能杜绝这种情况？

[Osk]

@selfcreditgiving 公钥只是避免别人暴力试出密码, 但它进行中的尝试仍然会继续, 每次尝试都会记录 sshd 日志, 日志仍然会涨.

ssh 的部分建议:
不要用默认的 22 端口, 减少一些批量脚本工具有事没事的扫描.
不要使用密码登录, 而是使用公钥或者两步认证登录, 避免被试出密码进入.
禁止 root 用户登录.
限制 sshd 连接数, 但有把自己锁到外边无法登录的风险.
使用 sshguard, fail2ban 或者端口敲门等办法减少被扫描的次数.


另外, 建议使用跳板机管理你的服务器: 这样的话, 攻击者首先要破解了跳板机的登录才可以进行后续的扫描, 大大降低了其它生产服务器被 ssh 暴力攻击的次数, 跳板机的 sshd 日志涨就让它涨吧, 反正生产服务器不涨就行.

当然, 使用 vpn 来保护也是不错的方案, 不过我觉得 vpn 可能也有被扫描的问题, 不如把 sshd 的安全做好.


至于如何做, 确实没有很统一的做法, linux 发行版间碎片化太严重了, 只能根据你当前的发型版去看官方的 wiki 或者手册.


另外, windows rdp 3389 更不好搞, 两部认证, 证书登录什么的, 都相当不容易配置, 比 ssh 配置麻烦多了.

[EIlenZe]

@Osk 每次看到这些就会想 要是世界上没有怀有恶意的人 是不是就可以不用做那么多工作了…

[laucenmi]

osx 升级 openssh 后遇到过某些服务器不能登录的问题, 在.ssh/config 对 host 添加了
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedKeyTypes +ssh-rsa
才可以工作.

[selfcreditgiving]

@Osk 多谢说的太详细了！
还有都配好后，用一个非 root 账户，每次 sudo 要输密码，同时命令前又要加个 sudo ，敲起命令来好累啊

[acmore]

@EIlenZe 那么世界上也会失去很多工作岗位（狗头

[dddd1919]

兄弟，你私钥呢？

[shangyu7]

看看 ssh 版本

[pixelcn]

一台是 RPM 系的吧？有 bug
PubkeyAcceptedKeyTypes 加上 rsa-sha2-512,rsa-sha2-256

[ziseyinzi]

应该是 17 楼说的，openssh 版本问题。新版本 openssh 因为安全原因会拒绝 rsa 算法的 key 。升级服务端的 openssh 版本或者在本地像 17 楼说的那样添加允许规则。

[ysn2233]

高版本的 openssh 加密算法换了，要配置一下

[selfcreditgiving]

抱歉，之前有事情现在才更新。

这两台服务器 是这样的，都是用 docker 起的 ubuntu 镜像容器，而且镜像是一模一样的。开放出了 ssh 端口。

这是两台服务器的 openSSH 版本 ssh -V

服务器 A 和 服务器 B 的结果都是一样的：
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g 1 Mar 2016

本身操作用的 macbook pro 的 ssh 版本：
OpenSSH_7.4p1, LibreSSL 2.5.0

/etc/ssh/sshd_config 两台服务器也是一模一样的。

@pixelcn @ziseyinzi @ysn2233 在登录失败的 服务器 B 设置了 /etc/ssh/sshd_config ，添加 PubkeyAcceptedKeyTypes rsa-sha2-512,rsa-sha2-256 ，并重启容器（因为 docker 容器里不能 用 service restart ）
结果还是一样的。

感觉我还是设一个强密码，然后设一个 fail2ban ，可不知道 fail2ban 有没有什么坑，可以设置好就不用管了不？

[selfcreditgiving]

@Osk
@dddd1919
@shangyu7
@pixelcn
@ziseyinzi
@ysn2233 发现原因了，又是自己的粗心大意浪费了大量的时间。

应该是 ~/.ssh 设置为权限 700
~/.ssh/authorized_keys 设置为 600

我设置反了！ 想当然 ~/.ssh/authorized_keys 是文件需要 执行权限， ~/.ssh 是文件夹 只要 读写权限就行了。

后面搜到才发现弄反了。

server A （成功）是因为 ， 没有手动去改 chomd 权限， ~/.ssh/authorized_keys 默认是 644 的权限。


经常会这样自己搞死自己，浪费大量的时间、熬夜，因为那一块是确认过了的，认为那里肯定是没有问题的，就没想到再去确认一次。大家有没有同样的经历？或者如果规避自己的低级错误导致卡壳的情况？

[selfcreditgiving]

目前找到一个 便利 和 安全 之间相对折中的方法， 就是：所有的服务器都用同一个 ssh 私钥。ssh 私钥设置 passphrase ，并且 passphrase 保存到 macOS 的 keychain （使用 ssh-add -K keyfile ）

[ynyounuo]

@selfcreditgiving
#13 我提到过这个问题，如果你当时有查看的话会省很多时间

[selfcreditgiving]

@ynyounuo #28 是的，自己太粗心了，认为这个方面是自己已经知道的，就没有仔细去看是应该文件夹设置 700 。