新しくCentOSでサーバを建て、sshコマンドを利用して他のサーバに接続しようとしたら、「Connection closed by xxx.xxx.xxx.xxx port xxxx」と表示されてSSH接続が出来ない。
原因を調査して対策します。
※動作確認環境
CentOS Linux 7.9
状況
- 外部からリモートホストとしてSSHでの接続を受ける際は正常に動作する。（sshdは正常に稼働している）
- sshコマンドで外部にSSH接続するときだけエラーが出てSSH接続が不可能。
- 接続先の相手を変えてもエラーが発生する。（どのサーバにもSSH接続できない。）
- 同様にrsyncもエラーが出て不可能。
- エラーが出たサーバへのSSH接続で利用した「公開鍵暗号方式のSSH Key（秘密鍵）」を、WindowsのSSHターミナルで利用した場合は問題無くそのサーバにSSH接続が可能。
これらの状況から、新しく構築したサーバ側に何か原因があると思われる。
原因調査
SSHのデバッグモードを利用してエラーの詳細を調査します。
【SSHのデバッグモードのオプション】
| オプション | デバッグ内容 |
|---|---|
| -v | クライアント側（接続元）のみの情報を表示 |
| -vv | クライアント側、リモートホスト側（接続先）の双方の情報を表示 |
| -vvv | クライアント側、リモートホスト側双方の詳細情報を表示 |
【デバッグ内容の種別】
| debug1: | クライアント側（接続元）の情報 |
| debug2: | リモートホスト側（接続先）の情報 |
| debug3: | 詳細な情報 |
今回は、SSHクライアント側の不具合の可能性が高いので「-v」オプションを利用して調査してみます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
# ssh -v -p xxxx -i /XXXXXX/XXXXXX/id_ed25519_xxxxxxxxxx_key xxxxx@xxx.xxx.xxx 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 xxx.xxx.xxx [xxx.xxx.xxx.xxx] port xxxx. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: key_load_public: No such file or directory debug1: identity file /XXXXXX/XXXXXX/id_ed25519_xxxxxxxxxx_key_key type -1 debug1: key_load_public: No such file or directory debug1: identity file /XXXXXX/XXXXXX/id_ed25519_xxxxxxxxxx_key_key-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_7.4 debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000 debug1: Authenticating to xxx.xxx.xxx:xxxx as 'xxxxx' debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256@libssh.org debug1: kex: host key algorithm: ssh-ed25519 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64 debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY ※ここで停止してしまう。 ※しばらく経った後に↓↓↓が表示されて終了。 Connection closed by xxx.xxx.xxx.xxx port xxxx |
「debug1: expecting SSH2_MSG_KEX_ECDH_REPLY」のところで1～2分ほどハングして止まってしまうので、ここで問題が発生していると思われます。
対策
ネットワークインタフェースのMTU値を変更（減少）して対策します。
まずip addrコマンドで現在のMTU値を確認します。
|
1 2 3 4 5 6 7 8 9 |
# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff inet 192.168.xxx.xxx/24 brd 192.168.xxx.255 scope global noprefixroute dynamic ens33 valid_lft 172796sec preferred_lft 172796sec |
デフォルトのMTU値は1500です。
次にnmcliコマンドでアクティブな接続プロファイルの概要を表示します。
|
1 2 3 |
# nmcli connection show NAME UUID TYPE DEVICE System ens33 XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX ethernet ens33 |
詳細を調べます
|
1 2 3 4 5 6 7 8 9 |
# nmcli connection show "System ens33" connection.id: System ens33 connection.uuid: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX connection.stable-id: -- connection.type: 802-3-ethernet connection.interface-name: ens33 connection.autoconnect: はい connection.autoconnect-priority: 0 ...以下略... |
キーボードのqを押して終了します。
コネクションIDは「System ens33」、コネクションタイプは「802-3-ethernet」です。
以下の書式で、コネクションID「System ens33」のMTU値を1500から1200に変更してみます。
■MTU値の変更コマンド【書式】
nmcli connection modify [コネクションID] [コネクションタイプ].mtu [変更後のMTU値]
変更します。（※コネクションIDにスペースが含まれるのでダブルクォーテーションで囲んであります。）
|
1 |
# nmcli connection modify "System ens33" 802-3-ethernet.mtu 1200 |
MTU値の設定変更を反映させます。
|
1 |
# systemctl restart NetworkManager |
正常に変更されたか確認します。
|
1 2 3 4 5 6 7 8 9 |
# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1200 qdisc pfifo_fast state UP group default qlen 1000 link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff inet 192.168.xxx.xxx/24 brd 192.168.xxx.255 scope global noprefixroute dynamic ens33 valid_lft 172785sec preferred_lft 172785sec |
MTU値が正常に変更されました。
動作確認
SSHで再度接続してみます。
|
1 2 3 4 5 |
# ssh -v -p xxxx -i /XXXXXX/XXXXXX/id_ed25519_xxxxxxxxxx_key xxxxx@xxx.xxx.xxx The authenticity of host '[xxx.xxx.xxx]:xxxx ([xxx.xxx.xxx.xxx]:xxxx)' can't be established. ED25519 key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. ED25519 key fingerprint is MD5:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX. Are you sure you want to continue connecting (yes/no)? |
フィンガープリントの確認が出ました。
SSHの正常動作OKです。
備考・まとめ
今回は古いPCと中古のパーツを流用して作成したサーバだったので、このような症状が出たのかもしれません。
いろいろとMTU値を変えてテストしてみた結果、MTU値が1460までならOKで、1461以上でエラーが発生するという状態でしたが、念のために1200まで下げました。
SSHの設定は正しいはずなのに、何をやってもそのサーバからだけ接続が出来ないという状態のときは、ネットワークインタフェースの「MTU値」を少し下げてみましょう。
以上で解決です。
