プロキシ経由のSSH接続の動作
大学からインターネットに接続するたびに、Webブラウザーのプロキシを172.18.10.1:3128に設定する必要があります。 Webブラウザーのプロキシーを構成しているので、プロキシーは「HTTPプロキシー」であり、プロキシー・サーバーはHTTPヘッダーとパッカーの知識があるため、HTTP接続を受け入れることができると思います。
このプロキシを使用してSSH接続をセットアップできますか？はいの場合、この接続はどのように機能しますか？私のコンセプトは、SSHとHTTPは2つの異なるプロトコルであるため、ヘッダーとパケットの構造が異なるということです。このため、私の大学のHTTPプロキシサーバーはSSHトラフィックを転送できません。私が間違っていたら訂正してください。
さまざまなヘッダー（バナーとも呼ばれます）は正しく、プレーンなSSHはHTTPプロキシを経由しません。ただし、プロキシには組み込みのトラバーサルメソッドが付属しており、HTTPプロキシにはHTTP CONNECT Wordが付属しています。がHTTPプロキシかどうかわからないので、SOCKSプロキシに関する情報も追加します。
プロキシには、HTTPまたはSOCKSの2種類しかありません（他のプロキシは、多くの場合、単にハックを組み合わせたものです）。 3128は、Squidプロキシの（多かれ少なかれ）標準ポートであるため、プロキシの作成に使用されているソフトウェアである可能性が高いです。また、squidはHTTPまたはSOCKSプロキシのいずれかを実行できます。
FirefoxとChromeには、プロキシをHTTPプロキシまたはSOCKSプロキシとして使用する設定があります。これは、プロキシのアドレスを入力するオプションの横に書き込まれます。両方とも機能する場合は、squid両方を受け入れるように構成されています。
どちらの方法でも、ProxyCommandを使用してSSHを構成し、そのコマンドを使用してプロキシを通過できます。しかし、それでもプロキシ自体をトラバースできるコマンドが必要です。いくつかのオプションがあります。私のお気に入りはncat（NMAPで提供されるnetcatプログラム）です。以下の例ではそれを使用しますが、回答の最後にオプションを追加します。
~/.ssh/configの中に追加できます
ProxyCommand /usr/bin/ncat --proxy-type http --proxy 172.18.10.1:3128 %h %p
ここで、--proxy-typeはsocks4またはsocks5にすることもできます。 SSHはそのコマンドを使用してプロキシを通過し、接続を確立します。
別のオプション
次のように、プレーンなncも使用できます。
ProxyCommand /usr/bin/ncat -X connect -x 172.18.10.1:3128 %h %p
また、SOCKSの場合、-X引数は "4"（SOCKSv4）または "5"（SOCKSv5）にする必要があります。残念ながら、ncはプラットフォームごとに異なり、一部のオプションは使用できない場合があります。
プロキシの後にファイアウォールがまだある場合は、追加のトリックについて nix.SEでのGillesの回答 を参照してください。
追記
SquidでHTTP CONNECTを無効にできます。そしてそれが無効になっている場合、プロキシは有効なHTTPワードではない（GET、POSTなどの無効になっていない）トラフィックの通過を許可しないため、すべての賭けは無効になります。
ただし、HTTP CONNECTを無効にすることの大きな問題は、HTTPSトラフィックがプロキシを通過できないため、HTTPプロキシでHTTP CONNECTが無効になっている可能性が低いことです。
更新：プロキシは単に「ネイティブ」HTTPSの通過を許可できないのですか？
これは@Pacerierのコメントの質問です。完全な質問：
ファイアウォールは、HTTP CONNECT HTTPSをブロックしながら、ネイティブHTTPSを許可できませんか？
これについて詳しく説明します（プロキシについて本当に話しているため）。
プロキシは、HTTP CONNECT HTTPSをブロックしながらネイティブHTTPS接続を許可できませんか？
はいといいえ。まず、プロキシは、プロキシを経由しない接続をブロックせず、プロキシに直接接続する接続のみを決定します。理論的には、プロキシは「ネイティブ」HTTPSの通過を許可する可能性があります。問題は、「ネイティブ」HTTPSが暗号化されているため、基本的にバイトストリームであることです。 at TCP level。言い換えると、HTTPSは、パケットを調べることによって表示されるプロトコルではありません。つまり、仕様によるものです。
これに対する反論は、プロキシがストリームが最初にHTTPSハンドシェイクを実行するかどうかをチェックでき、両方の側がハンドシェイクを「完了する」場合、バイトストリームがこの接続を通過し続けることを許可することです。接続側がハンドシェイクに成功したかどうかはわからないことに注意してください。これも設計によるものであり、プロキシはハンドシェイクが送信されたかどうかしか知ることができません。
上記を前提として、HTTPSハンドシェイクを偽造して必要なものを送信するだけでよいので、任意のプロトコルにプロキシを使用できるようになります。これはほとんどのプロキシの目的に反します。つまり、OSIレイヤー7（HTTP）プロキシをOSIレイヤー4（TCP）プロキシに変更しました。また、レイヤー4プロキシでは、HTTP、HTTPS、FTP、LDAPのいずれを使用しているかは問題ではありません。
参考文献（あまり関連していませんが、そこからいくつかの情報を取得しました）