近期经常遇到ssh登录问题，不是卡顿就是拒绝，还有无法登录认证问题（新建用户可以登录，或权限太大无法登录）等，搞得焦头烂额，以下汇总整理，并继续更新中。
ssh问题定位或排查的日志或手段有：
1、登录时添加参数-v，了解详细的登录过程。如 ssh -v root@172.16.1.10
2、使用starce跟踪。strace -o trace.log ssh root@172.16.1.10
3、在系统内查看message日志
4、在系统内查看服务状态日志
先看下正常登录详情：
[monitor00@~]$ssh -v root@172.16.19.23
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to 172.16.19.23 [172.16.19.23] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/cscroot/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: Authenticating to 172.16.19.23:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@openssh.com compression: none
debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16
debug1: kex: diffie-hellman-group-exchange-sha256 need=16 dh_need=16
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-rsa SHA256:oR73znvjJ110Pjr8R99K3QeIAHqovMOX0FZGTrhdn9o
debug1: Host '172.16.19.23' is known and matches the RSA host key.
debug1: Found key in /home/cscroot/.ssh/known_hosts:517
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
'debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
'
debug1: Next authentication method: publickey
debug1: Trying private key: /home/cscroot/.ssh/id_rsa
debug1: Trying private key: /home/cscroot/.ssh/id_dsa
debug1: Trying private key: /home/cscroot/.ssh/id_ecdsa
debug1: Trying private key: /home/cscroot/.ssh/id_ed25519
debug1: Next authentication method: password
root@172.16.19.23's password:
debug1: Authentication succeeded (password).
Authenticated to 172.16.19.23 ([172.16.19.23]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
Last login: Wed Aug 2 10:04:49 2023 from 172.16.19.731、ssh登录过程中卡，或输入密码后无反应
首先，排除掉网络问题，可以通过ping看看是否存在高延迟，建议在内网同网段地址间测试，因同网段内延迟都小于1；
其次，测试ssh服务端口处于监听状态，可以通过telnet命令测试，观察是否卡；
经过以上两步，初步判断网络没有问题，22端口处于监听状态。剩下需要排查安全限制、ssh服务认证等内容。
再次，排查是否有安全限制，比如限制ip访问、密码错误次数、拒绝root登录等
最后，排查ssh配置是否可优化。比如UseLogin、UseDNS、GSS、pam.d等
导致ssh登录卡常见原因：
a、关闭DNS解析，编辑/etc/ssh/sshd_config ，修改 UseDNS no
UseDNS特性是SSH服务的安全增强特性，默认是打开的。开启后，服务端会先根据客户端IP进行DNS PTR反向查询，得到客户端主机名。再根据得到的客户端主机名进行DNS正向A记录查询，最后比对得到的IP与原始IP是否一致，用以防止客户端欺骗。尤其启用GSSAPI认证后，它需要借助于域名进行身份认证。
b、关闭UseLogin，编辑/etc/ssh/sshd_config ，将改行注释。
UseLogin是在交互式会话的登录过程中使用的，默认值是"no"，经常因为该项出现登录卡顿、或登录后直接被弹出。
c、关闭UsePAM，编辑/etc/ssh/sshd_config，将其改为UsePAM no
2、拒绝登录
a、查看iptables、selinux、hosts.deny等，建议先关闭系统内防火墙、selinux改成disabled、hosts.deny清空。
b、查看ssh的pam配置：cat /etc/pam.d/sshd和 cat /etc/pam.d/password-auth
3、权限太大无法登录-Permissions are too open
Permissions 0777 for '/home/用户/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/用户/.ssh/id_rsa": bad permissions
Permission denied (publickey).无法登录ssh，重启sshd也未启动成功，并提示权限太高，按照提示将其修改相应的权限，一般为600或400，只允许自己能访问。
4、输入密码后快速回退到重新登录界面
编辑/etc/ssh/sshd_config，尝试改变UsePAM no或UseLogin no