☰

仅特定位置拒绝 SSH 连接

tag-icon • tag-icon 14.04 server ssh
仅特定位置拒绝 SSH 连接

我和女朋友共用一个我为不同的东西设置的 Ubuntu 服务器。然而最近她遇到了一个问题，让我、她和我们各自的同事都感到困惑和困惑。

每当她在工作时使用工作单位的 WiFi 时，她都会使用 PuTTy 进行连接，但只会收到“服务器意外关闭网络连接”错误。在出现错误之前，她从未被提示输入密码。如果她将手机设置为连接笔记本电脑的热点，她就可以成功登录。如果她在家或在我家，她也可以使用同一台笔记本电脑（没有热点）登录。当手机连接到工作单位的 WiFi 时，她也可以使用手机登录。

在auth.log服务器上，我看到她尝试连接，但唯一的帖子是

refused connect from [IP-ADDRESS] ([IP-ADDRESS])

该日志中没有更多信息。

我们迄今为止尝试过的东西（包括“我非常怀疑这是否会起作用，但为什么不呢”的尝试）：

  • 删除 PuTTy 注册表输入以重置她计算机上的会话密钥。
  • 从头删除并添加她的服务器用户。
  • 运行 ssh-keygen -A 来更新密钥集，使用 sudo service ssh restart 来更新更改。
  • 尝试仅使用 IP 地址而不是网址登录。
  • 尝试使用 [用户名]@[服务器地址] 以及 [服务器地址] 形式登录。

  • 在 Chrome 中添加 SecureShell 插件来替换 Putty（结果相同，但错误略有不同）：

    ssh_exchange_identification: Connection closed by remote host NaCl plugin exited with status code 255

对于这里可能发生的事情还有其他想法吗？

编辑：

/etc/ssh/sshd_config 的内容，以及请求 iptables -L 时的输出：

# 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 yes

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

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
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 yes

# 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 without-password".
# 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 yes

另外；iptables -L 的输出：

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

编辑2：

我当然不能确定，但​​我认为她的工作不太可能阻止端口 22 上的出站流量，原因如下：

  1. 直到几天前它还运行良好。
  2. 她就职于一家研究 IT 的机构。那里的大多数人几乎虔诚地使用 Linux，我相信如果不能使用 SSH 连接，那里的大多数人都会非常生气。
  3. 那里的 IT 主管拥有信息学博士学位，他花了 5 分钟研究这个问题，也同样不知所措。我认为他应该比所有人都清楚，公司政策是否是封锁 22 端口。
  4. 我的服务器确实注册了入站连接请求，并主动拒绝了它。如果端口 22 被阻止，这是否会导致 auth.log 中根本没有任何更新？

答案1

refused connect from [IP-ADDRESS] ([IP-ADDRESS])

此特定消息由TCP 包装器库当它决定拒绝连接时。Ubuntu 是sshd使用 TCP 包装器构建的。

检查 ssh 服务器上的两个文件“/etc/hosts.allow”和“/etc/hosts.deny”。其中一个文件中有一个条目，导致来自该地址的 ssh 连接被拒绝。请参阅这些文件的 Ubuntu 手册页。

答案2

最终发生的情况可能是，其工作网络的网络管理员阻止 TCP 端口 22 出站和 UDP 端口 22 出站，以阻止 SSH 访问。这样做是出于安全考虑，因为数据会从内部网络“上传”到不受组织控制的服务器。这也是出于工作场所政策考虑。

作为一名 IT 安全专业人员，我有责任不提供可能危及共享服务器安全或工作场所安全的答案，但我在这里给你三个选项，并在下面的部分中列出我推荐的选项。其中一个可能违反了女朋友的工作场所政策，也会降低你服务器的安全性，另外两个是潜在的其他选择。

选项 1：尝试运行面向 Web 的 shell 客户端，或设置sshd为使用端口 80。

不建议

在这种情况下，唯一的解决方案是运行某种面向 Web 的 shell 客户端，但您可能需要一个 Web 服务器。另一个解决方案是由尼廷·穆特卡沃阿将您的 SSH 服务器置于端口 80 是另一种选择。 这两种选择都会给您带来多种安全风险，包括但不限于：

  • 将 SSH 放在 HTTP 端口上意味着许多服务器可能会尝试访问 IP 地址上的网页，但会访问 SSH 连接，这会带来安全风险，因为服务扫描程序会看到这一点。
  • 将本应被视为“安全”的服务放在 Web 端口上，将使你面临针对该端口的 Web 攻击
  • 将 SSH 放在面向 Web 的系统上将使您面临大量暴力攻击媒介。
  • 放置面向 Web 的基于 Web 的 Shell 客户端也会让你面临暴力破解的威胁
  • 设置面向 Web 的基于 Web 的 shell 客户端将使您面临来自以任何语言（Java、PHP 等）编写的“客户端”的攻击媒介，其中可能包括但不限于：
    • 远程代码执行漏洞
    • 权限提升漏洞
    • 拒绝服务漏洞。

这也会使你的女朋友面临违反职场政策的风险，因为她会做一些职场政策不允许做的事情。她可能会面临纪律处分，甚至被解雇。出于这个原因以及上述安全原因，您不应实施此选项。

选项 2：不尝试规避工作场所 IT 政策

受到推崇的

作为一名 IT 安全专业人士，我曾经因为工作场所其他人违反政策而不得不终止网络访问，我建议你的女朋友不会尝试从工作环境/网络通过 SSH 连接到您的共享服务器。如果网络上正在进行任何类型的审计，那么网络审计可能会显示有人试图通过 SSH 连接到不安全、未经审查的服务器。虽然您或您的女朋友可能没有任何恶意，但大多数工作场所的“网络/计算机可接受使用政策”将包括您不会在未经授权或绝对必要的情况下在网络上进行个人活动。另一件事可能是“您不得使用某些服务，例如：[列表]”。

我建议你查看一下女朋友工作场所的可接受使用政策，并确定她是否违反了该政策，是否足以让她面临纪律处分，例如取消网络访问权限、取消计算机访问权限或可能被解雇。 不要试图规避该政策，因为你的女朋友可能会因规避该政策而被解雇。

选项 3：如果 SSH 是因工作相关的任务而需要的，请联系主管/管理层，看是否可以给予女朋友限制豁免。

还推荐

如果工作场所需要访问共享 SSH 服务器，那么您的女朋友需要与她的主管沟通，以确定允许此类访问是否违反政策。然后管理层必须讨论是否可以授予访问权限，然后确定允许通过网络进行访问是否安全/合理。

这可能是第二安全的选择

答案3

某个东西或某个人可能在服务器上安装了软件，这些软件似乎改变了 Linux 网络系统中的某些默认值，您是否有自事件发生以来所有已安装软件的日志。我有，在卸载可疑软件之前，请查看可疑软件在系统中安装时做了哪些更改

答案4

尝试重新启动 ssh 服务：

/etc/init.d/ssh restart

相关内容