SSHマジック

多くの人が長い間SSHに精通していましたが、私のように、誰もがこれらの魔法の3文字の背後にある機会を疑っているとは限りません。 SSHを使用してさまざまな管理タスクを解決する私の小さな経験を共有したいです。



目次:



1) ローカルTCP転送

2) リモートTCP転送

3) 複数のノードにわたるTCP転送チェーン

4) TCP転送ssh接続

5) SSH VPNトンネル

6) パスワードレスアクセスについて簡単に

7) ありがとう(リンク)



1)ローカルTCP転送



簡単なことから始めましょう-ローカルTCP転送:



画像



特定のアプリケーションを備えたリモートhost2サーバーがあります。たとえば、ポート5432でTCP接続を受け入れるPostgreSQLサーバーです。このサーバーには、外部からポート5432への直接接続を許可しないファイアウォールがありますが、 SSHアクセス(デフォルトのポート22、変更することをお勧めします)。 クライアントアプリケーションによってワークステーション「host1」から「host2」上のPostgreSQLサーバーに接続する必要があります。



これを行うには、コンソールの「host1」で次のように入力します。



host1# ssh -L 9999:localhost:5432 host2







これで、「host1」でローカルポート9999を介してPostgreSQLサーバーに接続できます。



host1# psql -h localhost -p 9999 -U postgres







「host1」Windowsの場合
たとえば、PuTTyでは、これは次のように行われます。

設定ツリーを確認します:接続→SSH→トンネル。

次に、「送信元ポート」フィールドで「Destination」の9999をドライブします-localhost:5432、[追加]をクリックします。

その後、必要に応じてセッション設定を保存することを忘れないでください。

画像



仕組み
「host1」の「host2」のSSHサーバーに正常に接続した後、SSHクライアントはポート9999でリッスンを開始します。「host1」のポート9999に接続すると、「host2」のSSHサーバーはlocalhostとの接続を確立します自身「host2」)をポート5432に送信し、この接続を介してsshクライアントが受信したデータをポート9999の「host1」に送信します。

重要! 図に矢印で示されているすべての接続は、個別のTCP接続(セッション)です。



SSHサーバーのセットアップ
通常、ポート転送はデフォルトですでにsshdで有効になっています。

/ etc / ssh / sshd_config:

AllowTcpForwarding yes







「host2」自体ではなく、利用可能な任意のマシンでアプリケーションに接続することもできます。



画像



これを行うには、「localhost」の代わりにポートを転送するときに、「host3」などのホスト名を指定します。



host1# ssh -L 9999:host3:5432 host2







ここで、「host3」は(IPアドレスではなく名前の場合)既知であり、マシン「host2」からアクセス可能である必要があることに注意することが重要です。



「host1」を介して、「host3」上のサービスに他のホストへのアクセスを提供することもできます(「host1A」と呼びます)。



画像



これを行うには、ローカルポート9999が発生するインターフェイスのIPアドレスをssh接続コマンドに挿入します。



ssh -L 0.0.0.0:9999:host3:5432 host2







この例では、host1で使用可能なすべてのIPv4インターフェイスでポート9999が開かれます。



2)リモートTCP転送



しかし、たとえば、「host2」に白いIPアドレスがない場合、NATの背後にある場合、またはそれへのすべての着信接続が閉じている場合はどうでしょうか。 または、たとえば、「host2」にはWindowsがあり、SSHサーバーを配置する方法はありませんか?



この場合、リモートTCP転送があります。



画像



ここで、反対方向-"host2"から "host1"にssh接続を確立する必要があります。 つまり 管理ワークステーションはSSHサーバーになり、「host2」からSSH経由でアクセスできます。「host2」では、SSHクライアントを使用して接続する必要があります。



ssh -R 9999:localhost:5432 host1







「host2」Windowsの場合
たとえば、PuTTyでは、これは次のように行われます。

設定ツリーを確認します:接続→SSH→トンネル。

次に、9999を「ソースポート」フィールド、localhost:5432、「宛先」にドライブし、下の「リモート」を選択して、「追加」をクリックします。

その後、必要に応じてセッション設定を保存することを忘れないでください。



画像



仕組み
接続に成功すると、「host1」でSSHサーバーはポート9999でリッスンを開始します。「host1」でポート9999に接続すると、「host2」でSSHクライアントはポートでlocalhost(それ自体は「host2」)との接続を確立します5432で、この接続を介して「host1」のsshサーバーが受信したデータをポート9999に送信します。



また、ホスト「host2」を信頼していない場合、「host1」のセキュリティを確保するのはさらに困難になります。 ただし、これはこの記事の範囲外です。



そしてもちろん、あなたはどうにか(あなた自身または外部の助けを借りて)上記のコマンドを入力して「host2」の側からssh接続を開始する必要があり、「host1」には白いIPアドレスと開いたSSHポートが必要です。



ssh接続を確立すると、すべてが前の章と同様に機能します。



3)複数のノードにわたるTCP転送チェーン



閉じたネットワークでは、必要なノードに直接アクセスできないことがよくあります。 つまり たとえば、host1→host2→host3→host4のように、チェーンによってのみ目的のホストに移動できます。

host1# ssh host2

host2# ssh host3

host3# ssh host4

host4# echo hello host4








これは、たとえば、これらのノードがゲートウェイである場合や、ゲートウェイが近隣のサブネットでのみ使用可能な場合に発生する可能性があります。



この場合、チェーンでTCP転送を行うこともできます。



画像



ここでは、わかりやすくするためにポート9991、9992、9993が選択されていますが、実際には、すべてのノードで空いている場合は同じポート(たとえば、9999)を使用できます。



合計で、次の一連のコマンドを実行する必要があります。



host1# ssh -L 9991:localhost:9992 host2

host2# ssh -L 9992:localhost:9993 host3

host3# ssh -L 9993:localhost:5432 host4








仕組み
上記のコマンドが正常に実行されると、ノードで次の処理が実行されます。



  • 「host1」へ:ポート9991が開き、それに接続されると、データはssh-connectionを介して「host2」へのポート9992にリダイレクトされます。
  • 「host2」へ:ポート9992が開き、接続されると、データはssh接続を介してポート9993へ「host3」にリダイレクトされます。
  • 「host3」へ:ポート9993が開き、それに接続されると、データはssh-connection経由でポート5432へ「host4」にリダイレクトされます。


したがって、「host1」のポート9991に接続すると、データはチェーンに沿ってポート5432の「host4」にリダイレクトされます。



重要! 図に矢印で示されているすべての接続は、個別のTCP接続(セッション)です。



4)TCP転送ssh接続



sshを介して直接アクセスできないサーバーに接続する必要がある場合があり、sshサーバーのチェーンを介してのみアクセスできます(前の章を参照)。 これで、次のことを行うために必要な知識が得られました。



画像



host1# ssh -L 2222:localhost:2222 host2

host2# ssh -L 2222:host4:22 host3








したがって、「host1」のポート2222では、「host4」のSSH(22)ポートで転送するようになりました。 接続できます:



host1# ssh -p 2222 localhost

host4# echo hello host4








どうしてこれが必要なのでしょうか? たとえば、理由は次のとおりです。



# host4

host1# scp -P 2222 /local/path/to/some/file localhost:/path/on/host4

# host4

host1# scp -P 2222 localhost:/path/on/host4 /local/path/to/some/file

# TCP forwarding host4

host1# ssh -p 2222 -L 9999:localhost:5432 localhost

host1# psql -h localhost -p 9999 -U postgres

# , ssh -p ,

# scp -P








まあ、一般的に、今では「host4」がとても近いことは素晴らしいことです:)



結論:大量のネストをTCP転送することができます。



RSA指紋メモ
場合によっては、ssh -p 2222 localhostを最初に通過し、リモートサーバーのRSAフィンガープリントを受け入れるまでscpは機能しません。



同じポート(2222)を使用して異なるリモートサーバーにアクセスすると、以前のサーバーからのRSAフィンガープリントエラーが残ります。 〜/ .ssh / known_hostsから削除する必要があります。



5)SSH VPNトンネル



TCPポート転送は素晴らしい機能です。 しかし、さらに必要な場合はどうでしょうか? UDP経由のアクセス、複数のポートとホストへのアクセス、動的ポートへのアクセス? 答えは明らかです-VPN。 そして、バージョン4.3以降の全能SSHは、私たちの助けになります。



将来的には、このSSH機能は、いくつかの管理タスクに一時的なソリューションが必要な場合にうまく機能します。 永続的なVPNを構築するには、このオプションはTCP-over-TCPを必要とするため、最適ではありません。接続の速度に悪影響を及ぼします。



TCP転送の詳細
しかし、SSHを使用したTCPポートフォワーディングは、TCPポートフォワーディングではヘッダーと一緒に元のパケットではなく、アプリケーションデータのみが送信されるため、多くの場合、VPNよりも優れています。 //blog.backslasher.net/ssh-openvpn-tunneling.html



SSHサーバーのセットアップ:

sshd設定のPermitTunnelはデフォルトでオフになっています。/etc/ssh/sshd_configで有効にする必要があります。

PermitTunnel yes





または

PermitTunnel point-to-point







重要 :トンネルの新しいネットワークインターフェイスを上げるには、sshクライアントとsshサーバーの両方にスーパーユーザー権限が必要です。 これがどれほど危険かについては長い間議論することができますが、ほとんどの場合、sshサーバーには十分な設定があります。



PermitRootLogin without-password







したがって、パスワードによるルートログインを禁止し、他の手段、たとえばRSAキーを使用することでのみ許可します。これは、はるかに安全です。



sshdを再起動します。

sudo service sshd restart # centos





または

/etc/init.d/ssh restart # (debian/ubuntu)







-wマジックキーを使用すると、トンネルが上昇します。



host1# sudo ssh -w 5:5 root@host2







5:5は、それぞれローカルマシンとリモートのインターフェイス番号です。 ここで、ifconfigがインターフェースのリストで「tun5」を出力しないことに混乱するかもしれません。 これは、「ダウン」状態にあるためですが、「ifconfig -a」または「ifconfig tun5」を呼び出すと、インターフェースが表示されます。



host1# ifconfig tun5

tun5 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

POINTOPOINT NOARP MULTICAST MTU:1500 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:500

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)








インターフェイスのIPアドレスを割り当て、それらを上げます。



host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102

host2# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101








ファイアウォールがある場合は、tun5インターフェイスからの接続を許可することを忘れないでください。



host1# #

host1# sudo iptables-save > /tmp/iptables.rules.orig

host1# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT

host2# #

host2# sudo iptables-save > /tmp/iptables.rules.orig

host2# sudo iptables -I INPUT 1 -i tun5 -j ACCEPT








host1でこれを行う必要はありません。ここでは、pingが両方向で機能するようになっています。



pingをお楽しみください:



host1# ping 192.168.150.102

host2# ping 192.168.150.101








PostgreSQLの以前の例を考慮すると、スキームは次のようになります。



画像



そして、PostgreSQLサーバーに接続するコマンドは次のようになります。



host1# psql -h 192.168.150.102 -U postgres







1つのノードではなく、ネットワークへのアクセスを提供する必要がある場合は、これらのノードをゲートウェイにすることができます。 例:



host2# # IP forwarding

host2# sudo sysctl -w net.ipv4.ip_forward=1

host2# # IP forwarding host1

host2# sudo iptables -I FORWARD 1 -s 192.168.150.101 -j ACCEPT

host2# # IP forwarding host1

host2# sudo iptables -I FORWARD 1 -d 192.168.150.101 -j ACCEPT

host2# # IP host1

host2# sudo iptables -t nat -A POSTROUTING -s 192.168.150.101 -j MASQUERADE








host1# # , host2 192.168.2.x, host1

host1# # host2 192.168.2.x

host1# sudo ip route add 192.168.2.0/24 via 192.168.150.2

host1# # host1

host1# ping 192.168.2.1








作業が終了したら、net.ipv4.ip_forwardとファイアウォールを元の状態に戻すことを忘れないでください。



host1# sudo iptables-restore < /tmp/iptables.rules.orig

host2# sudo iptables-restore < /tmp/iptables.rules.orig








ネタバレの下で、インターネットの一時的な共有に関するより興味深いケース
インターネットアクセスが禁止されている閉じたネットワーク上にサーバーを構成する必要があると仮定しますが、それでもそこに抜け穴があります-単一のsshサーバーまたはsshサーバーのチェーンを介したアクセス。 たとえば、サーバーを構成するには、そのサーバーへのインターネットアクセスが必要です。 その後、サービス担当者に依頼するよりも、自分で設定する必要があるサーバーに一時的なインターネットアクセスを設定する方が簡単です。



host1ホストマシンからhost2サーバーへ、そこからhost3へ、そしてそこから必要なhost4へのsshアクセスがあるとします。 次に、sshのTCP転送を行います(host1でhost4にすぐに接続できる場合は、この手順をスキップしてください)。



host1# ssh -L 2222:localhost:2222 host2

host2# ssh -L 2222:host4:22 host3








次に、host4に接続し、tun5インターフェイスを上げます。



host1# sudo ssh -p 2222 -w 5:5 root@localhost

host1# # host4 : sudo ssh -w 5:5 root@host4

host1# sudo ifconfig tun5 192.168.150.101/24 pointopoint 192.168.150.102

host4# sudo ifconfig tun5 192.168.150.102/24 pointopoint 192.168.150.101








host4のルーティングテーブルを見て、次を見てみましょう。



host4# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5

192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0

0.0.0.0 192.168.56.254 0.0.0.0 UG 0 0 0 eth0








重要 ! 次に、インターネットを利用できるゲートウェイ192.168.150.101を使用して、デフォルトルートtun5インターフェースを作成することをお勧めします。 したがって、この段階では、デフォルトルートを置き換えるためにどのルートを追加する必要があるかを正確に知ることが重要です。 多くの場合、別々のネットワークへのルートは別々に割り当てられず、すべてのネットワークトラフィックが通過するゲートウェイでデフォルトルート(0.0.0.0/0)を設定するだけなので、これは重要です。 さらに、サーバーへのssh接続も元のデフォルトゲートウェイを使用する可能性があります。



簡単にするために、この例では、サーバーが通常の操作に192.168.56.0/24以外のルートを必要とせず、以前のssh host3が同じネットワークからのIPアドレスを持っていると仮定します。



デフォルトゲートウェイを使用して、元のルーティングテーブルを記憶し、どこかに書き込みます。

host4# route -n > routes.orig







host1をhost4のインターネットゲートウェイとして機能するように設定します。



host1# # IP forwarding

host1# sudo sysctl -w net.ipv4.ip_forward=1

host1# #

host1# sudo iptables-save > /tmp/iptables.rules.orig

host1# # IP forwarding host4

host1# sudo iptables -I FORWARD 1 -s 192.168.150.102 -j ACCEPT

host1# # IP forwarding host4

host1# sudo iptables -I FORWARD 1 -d 192.168.150.102 -j ACCEPT

host1# # IP host4

host1# sudo iptables -t nat -A POSTROUTING -s 192.168.150.102 -j MASQUERADE








念のため、デフォルトでは現在のルートからゲートウェイにグレーのネットワークを登録できます
登録されていない場合:

sudo ip route add 192.168.0.0/16 via 192.168.56.254

sudo ip route add 10.0.0.0/8 via 192.168.56.254

sudo ip route add 172.16.0.0/12 via 192.168.56.254










デフォルトルートをhost4に変更します(注意、上記の警告を参照してください!):



host4# sudo ip route replace default via 192.168.150.101

host4# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use Iface

192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0 tun5

192.168.56.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0

0.0.0.0 192.168.150.101 0.0.0.0 UG 0 0 0 tun5








インターネット全体ではなく、特定のIPアドレス/マスクのみが必要な場合、デフォルトルートを変更することはできず、ゲートウェイを介して必要なアドレスのみをtun5に追加します。



インターネットがあることを確認します。



host4# ping 8.8.8.8







素晴らしい。 DNSを構成するために残ります。 これを行うには多くの方法がありますが、最も簡単な方法は/etc/resolv.confファイルを編集してそこに行を追加することです:



nameserver 8.8.8.8

nameserver 8.8.4.4








その後、インターネットに完全にアクセスできるようになります。



host4# ping ya.ru







作業が終了したら、すべてを元の状態に戻すことを忘れないでください。



host1# # host1

host1# sudo iptables-restore < /tmp/iptables.rules.orig

host1# # net.ipv4.ip_forward








host2# # - host4:

host2# sudo ip route replace default via 192.168.56.254

host2# # DNS- /etc/resolv.conf








6)パスワードレスアクセスについて簡単に



パスワード認証は私たちのものではないということは誰もが既に知っていると思います。 ただし、念のため、RSAキーを使用して認証を設定する方法について簡単に説明します。



1.クライアントマシンで、ユーザー用に独自のRSAキーを生成します。



client1# ssh-keygen -t rsa







デフォルトでは、秘密鍵は〜/ .ssh / id_rsaに保存され、公開鍵は〜/ .ssh / id_rsa.pubに保存されます。 秘密鍵はあなたの目玉として保管し、誰にも渡さないでください。どこにもコピーしないでください。

キーを作成するときに、キーを暗号化するためのパスワード(パスフレーズ)を設定できます。



2.クライアント公開鍵は、sshサーバーの〜/ .ssh / authorized_keysファイル(これはログインするユーザーのホームディレクトリです)に、それぞれ別の行に保存する必要があります。 これを手動で行わないために、各クライアントで次のコマンドを使用できます。



ssh-copy-id user@sshserver







userはサーバー上のユーザー名であり、sshserverはsshサーバーの名前またはIPアドレスです。

ファイル許可〜/ .ssh / authorized_keys
Sabio UPD:sshサーバーで〜/ .ssh / authorized_keysファイルを手動で作成する場合は、次の権限を設定する必要があります。

chmod 0700 ~/.ssh

chmod 0600 ~/.ssh/authorized_keys










3.パスワードを入力せずに、キーでサーバーを入力できることを確認します(パスフレーズと混同しないでください)。

ssh user@sshserver





セットアップを完了し、すべてが機能することを確認するまで、サーバーとの少なくとも1つのアクティブなsshセッションを閉じないことをお勧めします。



4. SSHサーバー上の/ etc / ssh / sshd_configファイルのパスワードにログインする機能を無効にします。



PasswordAuthentication no







公開鍵で入力する機能は通常、デフォルトですでに有効になっています。



PubkeyAuthentication yes







通常、次の2つのオプションも無効にします。



GSSAPIAuthentication no

UseDNS no








場合によっては、これにより接続プロセスを高速化できます(たとえば、サーバーにインターネットアクセスがない場合)。



5. sshdを再起動します。

service sshd restart





または

/etc/init.d/ssh restart







エラーが発生した場合、/ var / log / secure logを確認するか、-v、-vv、または-vvvオプションを使用して詳細な接続ログを表示すると便利です。

ssh -vvv user@sshserver







7)ありがとう(リンク)



help.ubuntu.com/community/SSH_VPN

habrahabr.ru/post/87197

blog.backslasher.net/ssh-openvpn-tunneling.html



All Articles