web-dev-qa-db-ja.com

特定の場所からのみSSH接続が拒否されました

私と私のガールフレンドは、私が別のもののためにセットアップしたUbuntuサーバーを共有しています。しかし最近、彼女は私と彼女の同僚の両方が混乱し混乱させている問題を経験しています。

彼女は仕事のWiFiを使用して仕事をしているときはいつでも、PuTTYを使用して接続しますが、「サーバーがネットワーク接続を予期せず閉じました」というエラーを受け取ります。彼女はエラーの前にパスワードの入力を求められることはありません。ラップトップを接続するホットスポットとして携帯電話を設定すると、正常にログインできます。自宅または私の場所にいる場合は、同じラップトップを使用して（ホットスポットなしで）ログインすることもできます。また、彼女の電話が仕事のWiFiに接続されているときに、電話を使用してログインすることもできます。

サーバー上のauth.logに、彼女の接続試行が入っているのが見えますが、投稿されているのは1つだけです

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

そのログにはこれ以上の情報はありません。

これまでに試したもの（「これがうまくいくのではないかと思いますが、なぜできないのか」など）：

  • PuTTYレジストリ入力を削除して、コンピューターのセッションキーをリセットします。
  • サーバーユーザーを最初から削除して追加します。
  • Ssh-keygen -Aを実行してキーセットを更新し、Sudoサービスsshを再起動して変更を更新します。
  • WebアドレスではなくIPアドレスのみを使用してログインしてみてください。
  • [username] @ [serveraddress]と[serveraddress]の両方の形式を使用してログインしてみてください。

  • 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

EDIT2：

もちろんわかりませんが、いくつかの理由で彼女の仕事がポート22のアウトバウンドトラフィックをブロックする可能性は非常に低いと思います。

  1. 数日前まではうまく機能しました。
  2. 彼女は、基本的にITを研究する研究所である組織で働いています。そこにいる人々のほとんどはほとんど宗教的にLinuxを使用しています。SSH接続を使用できなければ、大多数の人々が非常に怒っていると思います。
  3. 情報学の博士号を持つITの責任者は、問題を5分間見て、困惑しました。そこにいるすべての人々の彼は、ポート22をブロックすることが会社の方針であるかどうかを知っているべきだと思います。
  4. 私のサーバーはインバウンド接続要求を登録し、積極的に拒否します。ポート22がブロックされた場合、auth.logの更新はまったく発生しませんか？
14.04serverssh
6
Geir K.H.
refused connect from [IP-ADDRESS] ([IP-ADDRESS])

この特定のメッセージは、接続を拒否することを決定したときに TCPラッパーライブラリ によって発行されます。 Ubuntuのsshdは、TCPラッパーを使用するように構築されています。

Sshサーバー上の2つのファイル「/etc/hosts.allow」と「/etc/hosts.deny」を確認します。これらのファイルの1つにエントリがあり、そのアドレスからのssh接続が拒否されます。 これらのファイルについては、Ubuntuのマニュアルページを参照 。

15
Kenster

最終的には、作業ネットワークのネットワーク管理者がTCPポート22アウトバウンドおよびUDPポート22アウトバウンドをブロックして、SSHアクセスをブロックしている可能性があります。これは、内部ネットワークから組織によって制御されていないサーバーにデータが「アップロード」されるというセキュリティ上の懸念のために行われます。これも職場の方針の問題として行われます。

ITセキュリティの専門家として、共有サーバーのセキュリティまたは職場のセキュリティを損なうような答えを提供しないことが私の義務ですが、ここで3つのオプションを提供し、どれを識別するか以下のセクションでお勧めするもの。 1つはガールフレンドの職場のポリシーに違反する可能性が高く、サーバーのセキュリティを損なう可能性もあります。他の2つは他の選択肢です。

オプション1：Webに面したシェルクライアントを試して実行するか、sshdを設定してポート80を使用します。

推奨しません

この場合の唯一の解決策は、何らかのWeb向けのシェルクライアントを実行することですが、Webサーバーが必要になる可能性があります。 Nitin J Mutkawoa が提案するもう1つのソリューションは、SSHサーバーをポート80に配置することです。 これらのオプションはいずれも、以下を含むがこれらに限定されないいくつかのセキュリティリスクにさらされます：

  • HTTPポートにSSHを配置すると、多くのサーバーがIPアドレスのWebページにアクセスしようとする可能性がありますが、代わりにSSH接続にヒットします。これは、サービススキャナーが見るようにセキュリティリスクになります。
  • 「安全な」サービスと見なされるべきものをWebポートに配置すると、ポートに対するWebベースの攻撃にさらされることになります。
  • Webに面したシステムにSSHを配置すると、多くのブルートフォース攻撃ベクトルが発生します。
  • WebベースのWebベースのシェルクライアントを配置すると、ブルートフォース攻撃も可能になります
  • WebベースのWebベースのシェルクライアントを配置すると、「クライアント」が記述されているもの（Java、PHPなど）からベクトルを攻撃する可能性があります。
    • リモートコード実行の脆弱性
    • 権限昇格の脆弱性
    • サービス拒否の脆弱性。

これはまた、職場のポリシーが拒否するように設定したことを行うことで、ガールフレンドを職場でのポリシー違反にさらします。彼女は、解雇。この理由と上記のセキュリティ上の理由から、このオプションを実装しないでください。

オプション2：しない職場のITポリシーを回避しようとする

推奨

過去に職場で他の個人のポリシー違反によりネットワークアクセスを終了しなければならなかったITセキュリティ専門家として、私の推奨事項は、あなたのガールフレンドがあなたにSSHしようとしないことです作業環境/ネットワークからの共有サーバー。ネットワークで何らかのタイプの監査が行われている場合、ネットワーク監査は、誰かが安全でない、吟味されていないサーバーにSSHを試みていることを示す場合があります。あなたやあなたのガールフレンドは個々に悪意を持たないかもしれませんが、ほとんどの職場の「ネットワーク/コンピュータ利用規定」には、許可または絶対的な必要なしにネットワーク上で個人的なアイテムを行わないことが含まれます。もう1つは、「[リスト]などの特定のサービスを使用してはならない」と述べている可能性があります。

ガールフレンドの職場の許容される使用ポリシーを確認し、彼女がこのポリシーに違反しているかどうかを判断することをお勧めします。 あなたのガールフレンドがそれを回避することによって解雇される可能性があるため、ポリシーを回避しようとしないでください。

オプション3：仕事関連のタスクにSSHが必要な場合は、監督者/管理者に連絡して、ガールフレンドに制限免除を与えることができるかどうかを確認します。

推奨

共有SSHサーバーへのアクセスが職場の要件である場合、あなたのガールフレンドはそのようなアクセスを許可することにより、ポリシー違反があるかどうかを判断するためにスーパーバイザーに相談してください。その後、管理者がアクセスを許可できるかどうかを話し合い、そこからネットワーク経由のアクセスを許可することが安全かどうかを判断する必要があります。

これはおそらく2番目に安全なオプションです

3
Thomas Ward

おそらく、Linuxネットワークシステムのデフォルトを変更するように思われるソフトウェアをサーバーにインストールした人、または誰かが、インシデントが始まってからインストールされたすべてのソフトウェアのログを持っていますか。私はそうし、あなたが容疑者をアンインストールする前に、あなたのシステムにインストールされたときに容疑者が何を変更したかを見てください

0
MIchael Odumosu