Майкрософт віддаленого робочого столу через перенесений через ssh порт

10

У мене ситуація, коли я надаю доступ до сервера Windows, пересилаючи віддалений порт 3389 на робочому столі з ssh з мого Mac на "всередину" інакше недоступної мережі.

Зараз я можу підключитися до версії Windows віддаленого робочого столу, але версія Mac Remote Desktop вимкнеться та не надає доступу. Це навіть при використанні IP-номера в якості хоста для підключення.

Будь-яка ідея, чому це відбувається і як я можу обійти це?

remote-desktop ssh

— Торбьорн Равн Андерсен
джерело

Це все ще бажано через змінене програмне забезпечення. Відкриття щедрості.

— Thorbjørn Ravn Andersen

Ви пробували з новим клієнтом, 2.1.2?

— Ruskes

Ще ні. У мене 2.1.0. Дякую, я спробую оновити.

— Thorbjørn Ravn Andersen

Я зберігав віртуальну коробку з встановленими вікнами для таких ситуацій. На жаль, я хотів би змусити все працювати на Макіні, але коли клієнт не може чи не надасть мені належного VPN - запускаючи ОС, вони пробивають дірки (або ще гірше, покладаються на нестандартну одноразову поведінку) у зрештою, їхній брандмауер набагато менше працює. Зрештою - я запускаю RDC, щоб побачити вікна, тому мало значення, що я також працюю локально. Оскільки явно вам потрібен клієнт Mac, чи можете ви перейти до VPN-з'єднання?

— bmike

Що станеться на Mac, якщо ви просто telnet localhost: перенаправлений порт? Чи працює це, як очікувалося? Здається, є проблема з вашим ssh-тунелем.

— дб

6

Не пересилайте місцевий порт 3389, різні версії віддаленого робочого столу занадто розумні для власного блага.

Мої звичайні кроки включають пересилання локального 3390 на віддалений 3389. Потім у MacRDC я використовую: localhost:3390як адресу для підключення.

Я не знаю, чи використовуєте ви щось для сприяння налаштуванню з'єднання ssh, але з командного рядка це буде щось на кшталт:

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

Де;
- 3390це місцевий порт для пересилання в моїй коробці.
- 172.16.5.32це хост віддалених вікон. і;
- 3389це порт віддаленого робочого столу (очевидно).

— Джейсон Салаз
джерело

Я хотів іти на це, але, на жаль, перехід через порт 3390 також не спрацював :( Я спробував додати ім'я хоста Windows-сервера до / private / etc / hosts (псевдонім до 127.0.0.1), щоб побачити, чи можу я обдурити будь-який механізм "шукайте HOST", але ні. Проти якої версії Windows це проти і на яку версію віддаленого робочого столу для Mac?

— Thorbjørn Ravn Andersen

MacRDC 2.0.1, Windows RDC пройшло так довго, що я не міг вам сказати. Я, здається, пам’ятаю, що це відбувалося з акціями mstsc з Windows XP і вперед.

— Джейсон Салаз

Ваш оригінальний коментар означає, що localhost:3390у вікні RDC не працювало? І ви спробували myhost:3390(з псевдонімом myhost у рядку 127.0.0.1 у файлі хостів) також безрезультатно?

— Джейсон Салаз

Крім того, чи отримуєте ви якийсь результат у вікні вашого терміналу? Збої на каналі чи щось подібне? Будь-які повідомлення про помилки, зовнішні до програми MacRDC?

— Джейсон Салаз

Зараз я знову подивився на це, включаючи хак "myhost-> localhost", і, здається, цього недостатньо. Колесо крутиться в MacRDP, намагаючись підключитися, але все-таки вимкнулося. У Console.app немає повідомлень. Я використовую спеціальний інструмент для порту вперед (немає доступу до ssh). Мені справді цікаво, що вона намагається зробити, що не вдається.

— Thorbjørn Ravn Andersen

5

Можливо, спробуйте це рішення:

встановити sshuttle (реалізує ssh tunnel / proxy, але також реалізує деякі зміни маршрутизації) ( https://github.com/apenwarr/sshuttle.git )
налаштуйте sshuttle тільки на маршрут для ip-адреси вікна Windows, до якого потрібно досягти:

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

Замінити:

1.1.1.1/32 з ip адресою хоста Windows. Якщо є кількість хостів, до яких вам потрібно отримати доступ, і вони знаходяться в одній підмережі, ви можете просто змінити / 32 на щось ширше, скажімо / 24.
Запустіть клієнт Mac RDP та спробуйте отримати доступ до IP-адреси машини Windows. Можливо, ви можете використовувати ім'я хоста, якщо ви також пересилаєте запити DNS у вікно, яке ви використовуєте як міст.

Це варіація методу -D3389, але використовує функції проксі-шкарпеток ssh.

— Крило Тан Вонг
джерело

1

Вражаюча ... хороша робота.

— Ruskes

П’ять років і надалі є найкращим рішенням цієї проблеми.

— Хассан

3

Windows Remote Desktop реалізує більше алгоритмів аутентифікації та шифрування, характерних для Windows. Це траплялося нам часто, адже нас змушують використовувати віддалений робочий стіл Windows нашими адміністраторами мережі, оскільки ми використовуємо методи аутентифікації, які OSX не застосовує. Давайте схрестимо пальці та сподіваємось, що Microsoft випустить відповідність для якнайшвидшого віддаленого робочого столу Windows.

— 19 год
джерело

Чи є у мене якісь пропозиції шукати, щоб MacRDP не вичерпався?

— Thorbjørn Ravn Andersen

Якщо час вичерпається, зв’язок взагалі неможливо встановити. У будь-якому випадку, як Windows досягає успіху в з’єднанні, я здогадуюсь про автентифікацію чи шифрування! :)

— 19h

3

Чи намагалися ви вимкнути вимогу до "Автентифікація на рівні мережі" з "Панелі управління -> Система -> Дозволити віддалений доступ" на цільовій машині?

Аутентифікація рідного рівня

— brablc
джерело

Він може підключитися до інсталяції Windows RDP .. так, так, він це зробив уже :)

— 19:00

1

Версія 2.1.1 додала підтримку NLA - див. Macupdate.com/app/mac/8431/microsoft-remote-desktop-connection : перевіряє особистість комп'ютера на базі Windows перед встановленням з'єднання з віддаленим робочим столом. Цю опцію можна вибрати під час підключення до комп’ютера, на якому працює ОС Windows Vista або Windows 7. Аутентифікація на рівні мережі захищена, ніж параметри аутентифікації в попередніх версіях Windows. Якщо ви відключите цю вимогу (ми говоримо про останній прапорець), він повинен мати можливість увійти з клієнтом 2.1.0 через тунель SSL.

— brablc

Вибачте, не бачили, що хотіли вказати на частину пострілу NTLM. Можливо, варто спробувати!

— 19h

Я фактично не впевнений, що NLA має відношення до NTLM. NLA просто намагається перевірити облікові дані перед тим, як принести користувачеві екран для входу. Це виключає один вектор атаки. Але його Windows знаходиться за брандмауером, тому йому не потрібно це враховувати.

— brablc

1

Спробуйте CoRD: введіть опис посилання тут

Я виявив, що він працює краще, ніж офіційний клієнт RDP, і має тенденцію легше обробляти недосконалі налаштування.

— Олексій
джерело

Зараз я використовую CoRD, але він має кілька зморшок, і я вважаю за краще використовувати офіційний клієнт.

— Thorbjørn Ravn Andersen

1

Клієнт OSX Microsoft Remote Desktop, здається, не підтримує метод аутентифікації за замовчуванням, який використовується у Windows 7+

Рішення полягає в тому, щоб зробити наступне на машині Windows:

Старт -> Редагувати групову політику
Конфігурація комп'ютера
- Адміністративні шаблони
  - Компоненти Windows
    - Послуги віддаленого робочого столу
    - Хост сеансу віддаленого робочого столу
      - Безпека
        
        Змініть "Потрібно використовувати специфічні підключення для віддаленого робочого столу (RDP)" на Увімкнено і виберіть RDP зі спадного меню.
        
        Змініть "Потрібна автентифікація користувача для віддалених з'єднань за допомогою аутентифікації мережевого рівня" на " Відключено"

Тепер ви зможете без проблем підключитися за допомогою клієнта віддаленого робочого столу OSX через тунель SSH.

— Йоаким
джерело

Я також зіткнувся з цією проблемою при спробі створити тунель SSH для машини Windows. Це справно працювало, використовуючи Putty на Windows. Однак, створивши такий самий тунель на OSX, через деякий час просто вичерпано. Якби тунель взагалі не був налаштований, клієнт віддаленого робочого столу негайно вийшов би з ладу, тому я знав, що він отримує якесь з'єднання.

— Йоаким

-1

Іноді просто оновлення програмного забезпечення вирішує проблему.

введіть тут опис зображення

До очікування вашої ОС ви повинні переконатися у правильній версії WRDC.

Оскільки у вас застарілий 2.1.0, вам слід оновити до одного з наступних. Вер. 2.1.1 від Microsoft або останньої версії. 2.1.2. знизу.

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

введіть тут опис зображення

Якщо оновлення програмного забезпечення не допомагає, і якщо ви не можете підключитися до IP-адреси, імені хоста чи імені комп'ютера, то, ймовірно, порт 3389 заблокований десь у вашій WAN.

Щоб перевірити настройки SSH тунелювання спробувати telneting до порту на локальному комп'ютері.

— Рускес
джерело

Будь ласка, додайте принаймні посилання :-) Також: Це лише здогадка чи ви перевірили, що це вирішує проблему?

— nohillside

1

dl.dropboxusercontent.com/u/18309066/…

— 19:00

@patrix У мене немає налаштування для перевірки, але я читав про це.

— Ruskes

1

На даний момент відповідь, здається, більше здогадка, ніж рішення. І завантаження бета-програмного забезпечення з анонімного облікового запису Dropbox теж не для слабкого серця!

— nohillside

1

2.1.1 - це безкоштовне завантаження для тих, хто хоче цього. Google знайде вас там, але принаймні поки що це посилання показує вам доступні завантаження: microsoft.com/en-us/download/…

— Tim B

-2

Переадресація до порту 3389 обов'язково доставить вам проблеми. Система розпізнає те, що ви намагаєтеся зробити, і в основному саме коротке замикання. Це недолік DIY Remote Desktop , imho.

1

Тоді чому це працює з Windows Remote Desktop, але не з Mac версією віддаленого робочого столу (від Microsoft)?

— Thorbjørn Ravn Andersen