明らかに使用中なのに、コマンドが何も表示しないのはなぜ？

ほぼ権限の問題です。lsof や ss はソケット自体は出しますが、他ユーザーのプロセスは所有者の列を伏せるので、システムアカウントやコンテナランタイム、launchd が起動したサーバーは sudo を付け直すまで持ち主不明のリスナーに見えます。Windows は逆で、netstat には何も出ないのに bind だけ失敗します。これは Hyper-V や WSL2、Docker Desktop が起動時に予約したポート帯に当たっている状態です。

ポートを掴んでいるプロセスは kill してよい？

何なのかを先に見てください。取り残された開発サーバーなら問題ありませんが、書き込み中のデータベースは別ですし、他が依存しているシステムサービスも同様です。持ち主がコンテナならコンテナごと停止してください。ホストから見えるプロセスを kill してもランタイムが再起動するだけです。どうしても止められないものなら、自分のサービスを別のポートへ移すほうが早く片付きます。

ローカルからは届くのに、別のマシンからは届かないのはなぜ？

0.0.0.0 ではなく 127.0.0.1 にバインドしているからです。各ページのコマンドがプロセス名と並べてバインド先アドレスを出しているのはこのためで、ループバックにバインドしたものはファイアウォールの設定に関係なく自分のマシンからしか届きません。最近は意図的にそれを既定にしているフレームワークも多いので、たいていはバグではなくフラグの問題です。すでに 0.0.0.0 なのに届かないなら、次に疑うのはホストのファイアウォールかクラウドのセキュリティグループです。

珍しいポート番号に移すと安全になる？

ほとんどなりません。インターネット全体を舐めるスキャナーはポート範囲を丸ごと走査し続けているので、稼げるのは数時間であって安全ではなく、代わりに関係者全員がその番号を覚える羽目になります。既定ポートを狙う無差別スキャンのログが減るという効果は確かにありますが、それだけです。結果を変えるのは認証と、送信元アドレスを絞ったファイアウォールと、そもそも外に出さないことです。

ポート 23 · Telnet

TCPIANA 割り当てありリモート接続

平文のまま端末をつなぐポート。スイッチやカメラ、組み込みボードでは今も出荷時の管理口で、そしてうっかり開けると数分でスキャナーに見つかるポートでもあります。

ポート 23 を使っているプロセスを特定する

自分の環境の行をそのまま実行してください。ポートを掴んでいるプロセス名と、バインドしているアドレスが出ます。たいていはそれだけで答えが分かります。

macOS
sudo lsof -nP -iTCP:23 -sTCP:LISTEN
待ち受けソケット 1 つにつき 1 行です。列は COMMAND、PID、USER、そして NAME で、NAME にバインド先のアドレスが入ります。`127.0.0.1:23` ならこのマシンからしか届かず、リモートのクライアントは永遠につながりません。`*:23` なら全インターフェイスです。`-n` はホスト名の逆引きを、`-P` はポート名の解決を止めるので、`telnet` ではなく数字のまま出ます。`-sTCP:LISTEN` は確立済みのクライアント接続を隠すフィルタなので、いま誰がつながっているかも見たいなら外してください。何も出ず lsof が終了コード 1 で終われば、そのポートは誰も持っていません。`sudo` なしでは自分のプロセスしか見えないので、root が持つデーモンは存在しないように見えます。
Linux
sudo ss -tlnp 'sport = :23'
`-t` で TCP、`-l` で待ち受けソケット、`-n` でポートを数値のまま、`-p` で所有プロセスを出します。見るのは Local Address:Port の列で、`0.0.0.0:23` は全 IPv4 インターフェイス、`127.0.0.1:23` はループバックのみ、`[::]:23` は IPv6 のワイルドカードで、たいていの Linux では IPv4 も受けます。ポートが socket activation されているとプロセスは `users:(("systemd",pid=1,fd=42))` と出ますが、telnet ではこれが普通で、異常のしるしではありません。`sudo` なしだと自分の所有でないものはこの列が空になります。
Linux
sudo netstat -tlnp | grep ':23 '
iproute2 の入っていないマシン向けの、net-tools 時代の書き方です。フラグの意味は同じで、最後の列が PID/Program name の組。ただし man ページ自身がこの値は「信用できない」と警告していますし、自分の所有でないソケットの値を見るには特権が要ります。grep のパターン末尾の空白は消さないでください。ないと `:23` が `:2323` や `:23000` にも当たります。
Windows
netstat -ano | findstr :23
`-a` で接続だけでなく待ち受けポートも、`-n` でアドレスとポートを数値のまま、`-o` で最後の列に所有 PID が付きます。PID から名前を引くには `tasklist /FI "PID eq 1234"`。絞り込みには注意が必要です。`findstr` は部分一致なので、`:23` は `:2323` にも、23 を含むエフェメラルな送信元ポートにも当たります。何かを kill する前に、Local Address の列が本当に `:23` で終わっているか確かめてください。

外側から確かめる

`nmap -Pn -p 23 192.0.2.10` は、ホストの外側から見て本当に知りたい一点だけを答えます。`-Pn` を付けるのは、ping を無視する機器をスキャン対象から外させないためです。`open` なら TCP ハンドシェイクが成立したということ。意図して開けた覚えのない機器なら、これはインシデントとして扱ってください。`closed` はホストがリセットを返した、つまり到達はできるが誰も待ち受けていない状態。`filtered` は何も返ってこなかった、つまりファイアウォールや ACL が拒否ではなく破棄しているということです。どれだったかは `--reason` で分かりますし、`-sV` を付ければ telnet のバナーを読んで、たいていは機器のベンダー名まで教えてくれます。スキャンは自分が責任を持つホストにだけ。

23 につながらないときの読み方

出ているもの	意味
`telnet: connect to address 192.0.2.10: Connection refused（接続を拒否された）`	パケットはホストまで届き、23 番を持つプロセスがないのでカーネルがリセットを返しました。デーモンが止まっているか、そもそも入っていないか、あなたが叩いたアドレスを含まない場所にバインドしています。上のコマンドは手元のノート PC ではなく、対象のホスト側で実行してください。
`telnet: connect to address 192.0.2.10: Operation timed out（接続がタイムアウトした）`	何も返ってきていません。パケットフィルタが SYN を黙って捨てています。ホスト上のファイアウォール、ネットワーク ACL、あるいはそもそも別の VLAN にいるかのどれかです。拒否なら即座に返り、破棄なら数十秒待たされます。この待ち時間そのものが診断結果です。
`Connected to 192.0.2.10. ... Connection closed by foreign host.（いったん接続できたあと、相手側に切断された）`	ポートは開いていてハンドシェイクも成立し、そのあとサーバー側から切られました。よくあるのは、接続は受け入れてから送信元アドレスで弾く TCP wrappers やアクセスリストの設定、同時に 1 セッションしか許さない機器に既に誰かがつながっている状態、あるいは起動直後に落ちたデーモンです。ネットワークの問題ではありません。アプリケーション層の手前までは全部成功しています。
`telnetd: bind: Address already in use（ポート 23 がすでに使用中）`	指定したアドレスの 23 番は既に誰かが持っています。自分の環境のコマンドを実行して出力のバインドアドレスを見て、本当に衝突しているのか確かめてください。`0.0.0.0:23` を持つプロセスがいると `192.0.2.10:23` への二度目の bind は失敗しますが、別々の具体的なアドレスに 2 つ並ぶぶんには問題なく共存します。
`bind: Permission denied（一般ユーザーでポート 23 の待ち受けを始めようとして権限エラー）`	Unix 系では 1024 未満が特権ポートなので、カーネルは他を何も見ずに EACCES で bind を断ります。init システム経由で root として起動するか、Linux ならバイナリに `CAP_NET_BIND_SERVICE` を与えるか、高い番号で待ち受けて転送してください。ポートは空いています。あなたに使う権限がないだけです。

ポート 23 で動いているもの

IANA は 23 番を TCP・UDP 両方で `telnet` に割り当てていて、根拠は RFC 854 ですが、実際に使われるのは TCP だけです。Telnet は文字ストリームをそのまま流す端末プロトコルで、暗号化も完全性の検査も一切ありません。ログイン名もパスワードも、その後のキー入力も、すべて読めるバイト列のまま流れます。汎用マシンのまともなログイン手段としては 20 年前に役目を終えているのに、ネットワークスイッチ、IP カメラ、DVR、セットトップボックス、シリアルコンソールサーバー、産業機器、ホビーボードの工場出荷時の管理インターフェイスとしては生き残っていて、誰も出すつもりのなかったネットワークに顔を出し続けています。エンジニアがこの番号を調べる理由には、まったく別のものがもう一つあります。`telnet host 25` のように、何か応答するかを確かめるだけの素の TCP 叩きです。こちらはクライアント側の話でリスクは何もありません。同じことは `nc -vz host 25` でもできますし、macOS といくつかの Linux ディストリビューションは telnet クライアントを既定で入れなくなったので、今はそちらが主流です。プロセスを探しに行く前に一つだけ。telnetd は常駐せず必要になってから起動する作りが伝統なので、socket activation の効いた systemd ホストや、古い inetd・xinetd のマシンでは、23 番を掴んでいるのは `systemd` や `inetd` として出てきます。telnetd 自体は接続が来て初めて存在します。

ポート 23 を外部に開けてよいか

23 番はインターネットに出さないでください。できればオフィスのネットワークにも出さないほうがいいです。クライアントとサーバーの間にいるもの——スイッチ、乗っ取られたルーター、同じ Wi-Fi にいる別のマシン——はパスワードを平文で読めますし、サーバー証明書もないので、間に誰かが入っていても気づく手段がありません。公開された telnet のリスナーは全世界を舐めるスキャナーに絶えず見つけられ、見つかった瞬間からベンダーの初期パスワード一覧を片端から試されます。家庭用機器で組み上げられた大規模なボットネットは、歴史的にこの手口で作られてきました。しかも組み込み機器で動いているのは、たいてい更新の止まった古いデーモンです。正しい置き換えは 22 番の SSH で、同じシェルをホスト鍵の検証と暗号化つきで使えます。どうしても telnet しか話さない機器なら、管理用 VLAN に閉じ込めて SSH の踏み台か VPN 経由でしか届かないようにし、ネットワークに繋ぐ前に工場出荷時のパスワードを変え、ルーターが実際に何を転送しているかを確認してください。UPnP には、頼んでもいないポートを勝手に公開してきた長い前科があります。「NAT の内側だから大丈夫」は検証できない対策です。ポート転送のルールや UPnP のマッピング一つで、黙って無効になります。

サービス: Telnet
トランスポート: TCP
登録状況: IANA 割り当てあり
カテゴリ: リモート接続

このサイトのツール

どれもブラウザ内で完結します。アップロードは発生しません。