ssh転送ポートを介したMicrosoftリモートデスクトップ

10

私のMacからリモートデスクトップポート3389をsshで転送して、Windowsサーバーへのアクセスを提供している状況にあります。

これでWindowsバージョンのリモートデスクトップに接続できますが、Macバージョンのリモートデスクトップはタイムアウトし、アクセスできません。これは、接続するホストとしてIP番号を使用する場合でも同じです。

これがなぜ起こるのか、そしてどうすればそれを回避できるのか？

remote-desktop  ssh 
— トールビョルンラウンアンデルセン
ソース
ソフトウェアの変更により、これはまだ望ましいことです。バウンティを開く。
— –ThorbjørnRavn Andersen 2013
新しいクライアント2.1.2で試しましたか？
— Ruskes 2013
未だに。2.1.0を持っています。ありがとう、アップグレードしてみます。
— –ThorbjørnRavn Andersen 2013
このような状況のために、ウィンドウがインストールされた仮想ボックスを保持しました。悲しいことに、私は物事をMacでネイティブに動作させたいと思っていますが、クライアントが適切なVPNを提供できない、または提供しない場合、OSを実行します（または、さらに悪いことに、非標準の1回限りの動作に依存します）。彼らのファイアウォールは結局のところ私にとってはるかに少ない仕事です。結局のところ、私はウィンドウを表示するためにRDCを実行しているので、そのOSをローカルで実行していることはほとんど問題になりません。Macクライアントが明示的に必要なので、VPN接続にSSH接続できますか？
— bmike
単純にtelnet localhost：forwarded portとすると、Macはどうなりますか？期待どおりに動作しますか？sshトンネルに問題があるようです。
— db

回答:

5

ローカルポート3389を転送しないでください。リモートデスクトップのさまざまなバージョンは、自分の利益にはあまりにもスマートです。

私の通常の手順は、ローカル3390をリモート3389に転送localhost:3390することです。次に、MacRDCでは、接続するアドレスとしても使用します。

ssh接続のセットアップを支援するために何かを使用しているかどうかはわかりませんが、コマンドラインからは次のようになります。

ssh -L 3390:172.16.5.32:3389 jason@remote.net

どこ;
- 3390私のボックスのローカル転送ポートです。
- 172.16.5.32リモートのWindowsホストです。そして;
- 3389リモートデスクトップのポートは、（明らかに）です。

— ジェイソンサラズ
ソース
私はこれでやりましたが、残念ながらポート3390を経由しても機能しませんでした：（Windowsサーバーのホスト名を/ private / etc / hosts（別名127.0.0.1）に追加して、だまされないかどうかを確認しました。？任意の「HOSTため見た目」のメカニズム、ない何のWindowsのバージョンは反対とMac用のリモートデスクトップのバージョンをこのです
— するThorbjörnRavnアンデルセン
MacRDC 2.0.1、Windows RDCそれは私があなたに伝えることができなかったのでとても長い間です。私はそれがWindows XP以降の標準のmstscで起こったことを覚えているようです。
— Jason Salaz、2011
元のコメントはlocalhost:3390、RDCウィンドウが機能しなかったことを意味しますか？また、myhost:3390（hostsファイルの127.0.0.1行でエイリアス化されたmyhostを使用して）同様に試しましたが、役に立ちませんでしたか？
— Jason Salaz、2011
また、ターミナルウィンドウに出力が表示されますか？チャネルの障害またはそのようなものは何ですか？MacRDCアプリの外部にあるエラーメッセージはありますか？
— Jason Salaz、2011
「myhost-> localhost」ハックを含め、これをもう一度見ましたが、それだけでは十分ではないようです。接続しようとするMacRDPでホイールが回転しますが、それでもタイムアウトします。Console.appにメッセージはありません。カスタムツールを使用してポートフォワードします（sshアクセスなし）。私は本当にそれが何をしようとするのか失敗するのかと思います。
— –ThorbjørnRavn Andersen 2013
5

あなたのMacで、おそらくこの解決策を試してください：

  • sshuttleをインストールします（sshトンネル/プロキシを実装しますが、ルーティングの変更も実装します）（https://github.com/apenwarr/sshuttle.git）

  • 到達したいWindowsボックスのIPアドレスにのみルーティングするようにsshuttleを構成します。

    sshuttle --dns -r YourUserName@YourSSHBox.com 1.1.1.1/32

    交換：

    1.1.1.1/32とWindowsホストのIPアドレス。アクセスする必要のあるホストが多数あり、それらが同じサブネット内にある場合は、/ 32をより広いもの、たとえば/ 24に変更することができます。

  • Mac RDPクライアントを起動し、WindowsマシンのIPアドレスにアクセスしてみます。ブリッジとして使用しているボックスにDNSクエリも転送している場合は、おそらくホスト名を使用できます。

これは-D3389メソッドのバリエーションですが、sshのsocksプロキシ機能を採用しています。

— ウィングタンウォン
ソース
1
印象的...良い仕事。
— Ruskes 2013
5年経った今でも、この問題に対する最善の解決策です。
— Hassan
3

ターゲットマシンの「コントロールパネル->システム->リモートアクセスを許可」から「ネットワークレベル認証」の要件を無効にしようとしましたか？

ネイティブレベルの認証

— Brablc
ソース
彼はWindows RDPインストールで接続することができます。そうです、そうです、彼はすでにそれをしました:)
— ケナン・スレイマン
1
バージョン2.1.1はNLAのサポートを追加しました-macupdate.com/app/mac/8431/microsoft-remote-desktop-connectionを参照してください： リモートデスクトップ接続を確立する前に、WindowsベースのコンピューターのIDを確認します。このオプションは、Windows VistaまたはWindows 7を実行しているコンピューターに接続するときに選択できます。ネットワークレベル認証は、以前のバージョンのWindowsの認証オプションよりも安全です。 この要件を無効にすると（最後のチェックボックスについて説明します）、SSLトンネルを介して2.1.0クライアントでログインできるはずです。
— brablc
ショットのNTLM部分を指摘したいとは思わなかった。たぶん試してみる価値あり！
— ケナンスレイマン2013
NLAがNTLMに関連しているのかどうか、実際にはわかりません。NLAは、ログイン画面をユーザーに表示する前に、資格情報を検証しようとします。これにより、1つの攻撃ベクトルが排除されます。しかし、彼のWindowsはファイアウォールの背後にあるため、これを考慮する必要はありません。
— brablc 2013
2

Windowsリモートデスクトップは、Windows固有の認証および暗号化アルゴリズムを実装しています。OSXが実装していない認証方法を使用しているため、これは頻繁に起こりました。実際、ネットワーク管理者はWindowsリモートデスクトップを使用せざるを得ませんでした。指を交差させて、MicrosoftがWindowsグレードのリモートデスクトップ向けのマッチをできるだけ早くリリースすることを期待しましょう。

— ケナン・スレイマン
ソース
MacRDPがタイムアウトにならないようにするために私が探している提案はありますか？
— –ThorbjørnRavn Andersen 2013
タイムアウトになると、接続をまったく確立できません。いずれにせよ、Windowsが接続に成功するので、私の推測は認証または暗号化です！:)
— ケナン・スレイマン2013
1

OSX Microsoftリモートデスクトップクライアントは、Windows 7以降で使用されるデフォルトの認証方法をサポートしていないようです

解決策は、Windowsマシンで以下を実行することです。

  • スタート->グループポリシーの編集

  • コンピューター構成

    • 管理用テンプレート

      • Windowsコンポーネント

        • リモートデスクトップサービス

        • リモートデスクトップセッションホスト

          • 安全保障

            1. 変更のリモートデスクトップ（RDP）接続のための特定の使用要求"に有効を選択しますRDPをドロップダウンから。

            2. 変更は、「ネットワークレベル認証を使用して、リモート接続のためのユーザー認証を要求」に無効

これで、OSXリモートデスクトップクライアントを使用して、SSHトンネル経由で問題なく接続できるはずです。

— ヨアキム
ソース
WindowsマシンへのSSHトンネルを作成しようとしたときにも、この問題に遭遇しました。WindowsでPuttyを使用する場合、問題なく動作しました。ただし、OSXでまったく同じトンネルを作成すると、しばらくするとタイムアウトしました。トンネルがまったくセットアップされていなかった場合、リモートデスクトップクライアントはすぐに失敗するため、なんらかの接続が確立されていることがわかりました。
— Joakim 14年
-1

ソフトウェアをアップデートするだけで問題が解決する場合があります。

ここに画像の説明を入力してください

OSを保留する場合は、正しいバージョンのWRDCがインストールされていることを確認してください。

古い2.1.0を使用しているため、次のいずれかに更新する必要があります。Ver。2.1.1 Microsoftまたは最新バージョンから。2.1.2。下から。

http://www.cloud9realtime.com/Guides/Macintosh%20RDP%20Guide.pdf

ここに画像の説明を入力してください

ソフトウェアの更新が役に立たず、IPアドレス、ホスト名、またはコンピューター名で接続できない場合は、WANのどこかでポート3389がブロックされている可能性があります。

sshトンネリング設定をテストするには、ローカルマシンのポートにtelnetしてみてください。

— ラスク
ソース
少なくともリンクを追加してください:-)また：これは単なる推測ですか、それとも問題が解決することを確認しましたか？
— ノーヒルサイド
1
— ケナンスレイマン
@patrix確認するための設定はありませんが、それについて読みました。
— Ruskes 2013
1
現時点では、答えは推測よりも解決策のようです。また、匿名のDropboxアカウントからベータ版ソフトウェアをダウンロードすることも、気弱な人には向いていません。
— nohillside
1
2.1.1は、代わりにダウンロードしたい人のための無料ダウンロードです。：Googleはあなたに利用可能なダウンロードがあなたを得るが、少なくとも今、このリンクのショーのためになるmicrosoft.com/en-us/download/...
— ティム・B
-2

ポート3389に転送すると、問題が発生します。システムはあなたがやろうとしていることを認識し、基本的にそれ自体を短絡させます。これは、DIY リモートデスクトップの欠点です。

1
では、なぜそれがWindowsリモートデスクトップで動作するのに、Macバージョンのリモートデスクトップ（Microsoftからも）では動作しないのですか？
— –ThorbjørnRavn Andersen、2011
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.