Какие есть наиболее простые способы переписать файл из Windows в Linux?

[MiK13]

Всем здравствуйте! И не поддавайтесь коронавирусу
Возникла задача. Надо у заказчика обновить основную программу. А заказчик далеко. Да и квалификация небольшая.
Для обновления файлов сделал небольшой скрипт, который распаковывает прикреплённый к нему tgz-архив и копирует файлы в заданные каталоги, переименовывая существующие. Но возникла проблема: как передать файл.
Самое простое -- отправить по почте. Но, как сказал начальник, они его примут на ноутбук с Windows. А как переписать на Linux?
Сложность в том, что, опять же со слов начальника, там высокие требования к безопасности. Какие именно -- я не знаю.
Поэтому на компьютере (RHEL отключена возможность переписать файл через USB-флешку. Про FTP начальник сказал: "Никакого FTP, только SFTP".
Поэтому возникла мысль отправить архив.zip с тремя файлами: prog_upd.sh (для обновления), send.bat и pscp.exe.
Файл send.bat с одной строкой: pscp.exe prog_upd.sh user@host:/home/user
Но pscp.exe ставится вместе с пакетом PuTTY. И он что-то добавляет для обмена ключами. А если там PuTTY не стоит?
Стал проверять. Нашли ноутбук с виндой, на которой не стоит PuTTY (почти на всех компьютерах в отделе PuTTY стоит).
Когда я попробовал с помощью pscp передать файл, в ответ выскочило какое-то сообщение, что требуется обмен ключами. То же самое выскочило, когда я попробовал подключится с помощью putty.exe (без установки).
Параллельно со мной другой сотрудник установить на ноутбук PuTTY и проблема передачи файла (у нас) пропала. Но что будет у заказчика?
Я нашёл в интернете архив PuTTY_PORTABLE с программами этого пакета. Может быть его не надо устанавливать и для pscp.exe будет достаточно первый раз подтвердить доверие удалённом хосту?
Или, может быть, есть ещё какие-то простые способы переписать принятый на ноутбук с Windows файл на компьютер с Linux?

[devilr]

Ну так может проще у безопасников спросить? Раз уж "высокие требования к безопасности".
А то ведь всякое бывает - флешка блокирована, а интернет - нет. Например. Особенно в РФ.

[MiK13]

Ну так может проще у безопасников спросить? Раз уж "высокие требования к безопасности".
А то ведь всякое бывает - флешка блокирована, а интернет - нет. Например. Особенно в РФ.

Интернета на том компьютере нет. Там, как я понимаю, вообще изолированная сеть.
Интернет есть в другом месте. И принять они могут на ноутбук. А потом надо как-то переписать на основной компьютер.
И дать подробные инструкции. Типа.
На ноутбуке:

1. Распаковать zip-архив.
2. Запустить файл send.bat (возможно перед этим нажчть Win+E, набрать cmd и нажать "Enter")
3. На запрос ответить 'y'

На рабочем компьютере:

1. Зайти под именем $USER
2. Ввести пароль
3. Вызвать терминал
4. Выдать команду chmod +x prog_upd.sh
5. Выдать команду ./prog_upd.sh
6. Выдать команду gedit /usr/local/bin/Prog/settings/settings.ini
7. Сделать необходимые изменения в файле.
8. Нажать Ctrl+S чтобы сохранить файл
9. Нажать Alt+F4 чтобы закрыть редактор
10. Завершить сеанс

И то я не уверен, что всё сделают правильно.

[devilr]

Предприятие не режимное, случайно?
P.S. Это я к тому, что ежели режимное, то должны быть правила для передачи файлов. И можно запросто оказаться крайним при их нарушении.

[Hephaestus]

MiK13
Слушайте, не занимайтесь ерундой.
Вы предоставляете заказчику обновление продукта. Теоретически, Вы вообще можете разместить обновление на сайте и дать клиенту ссылку.
А уж каким способом он всё это доставит на целевую машину - это исключительно его проблемы.
Тем более, что Вы даже не знаете деталей, где там что.
В конце концов, это их контора, их локальная сеть, их машины, их система безопасности. Их, а не Ваши.
Они ДОЛЖНЫ знать, как работать в собственной сети, а Вы, наоборот, НЕ должны знать, как там чего устроено.

[ormorph]

Они ДОЛЖНЫ знать, как работать в собственной сети, а Вы, наоборот, НЕ должны знать, как там чего устроено.

Некоторые конторы по разработке берут на себя обязанность по развёртыванию ПО у заказчика. Но это обычно сразу оговаривается до начала разработки.
А так это все согласовывается с конторой, которая обслуживает локальную сеть. Ну и возможно там вообще компьютеры с Linux являются терминалами, а ОС находится на отдельном сервере. По этому установка ПО через локальную сеть сродни хакерству. Скорее всего просто кто то хочет сэкономить и провести это мимо конторы, которая обслуживает локальную сеть.

[Hephaestus]

Некоторые конторы по разработке берут на себя обязанность по развёртыванию ПО у заказчика.

Здесь явно не тот случай. Иначе этой темы просто не было бы.

По этому установка ПО через локальную сеть сродни хакерству.

Не более, чем любая другая установка. Кстати, контора, обслуживающая ЛВС тут вообще сбоку. Проложили кабели, настроили адресацию/маршрутизацию и ушли. Дальше должны работать местные сисадмины (на которых установка ОС и ПО) и безопасники (на которых всякое там "закручивание гаек"). Так вот этих веселых ребят (админов и безопасников) и нужно напрягать в данном случае.

Скорее всего просто кто то хочет сэкономить и провести это мимо конторы, которая обслуживает локальную сеть.

Если там совсем суровые требования к безопасности, то вряд ли у них служба безопасности "внешняя" по отношению к конторе (это , конечно, возможно, но тогда вообще грустно - любой чих через внешнюю контору проводить).

[Bizdelnick]

Чтобы не приходилось извращаться, нужно было с самого начала нормально опакетить софт и поставлять обновления через репозиторий. Если у клиента изолированная сеть — пусть делает в ней зеркало репозитория. И всех дел.

[MiK13]

MiK13
Слушайте, не занимайтесь ерундой.
Вы предоставляете заказчику обновление продукта. Теоретически, Вы вообще можете разместить обновление на сайте и дать клиенту ссылку.
А уж каким способом он всё это доставит на целевую машину - это исключительно его проблемы.

Лично я считаю также. И если кому-то поставляется система на базе компьютера, то атм должны быть люди, которые знают как с ним работать.

Они ДОЛЖНЫ знать, как работать в собственной сети, а Вы, наоборот, НЕ должны знать, как там чего устроено.

Тут есть одна особенность. Их локальная сеть скорее "наша". То есть мы им поставили устройство, которое оцифровывает сигналы с некоторого другого устройства и выдаёт их в локальную сеть. В которой пока всего 2 АРМа На каждом по несколько сетевых интерфейсов. Через один из которых ОНИ могут подключиться, чтобы получать некоторую информацию. Причём, я прописал в этой сети только локальные пути.
Для "входа" в эту сеть есть скрипт, который командой route добавляет (или удаляет) для определённого интерфейса путь к конкретному IP адресу.

Проложили кабели, настроили адресацию/маршрутизацию и ушли. Дальше должны работать местные сисадмины (на которых установка ОС и ПО) и безопасники (на которых всякое там "закручивание гаек"). Так вот этих веселых ребят (админов и безопасников) и нужно напрягать в данном случае.

Если они там вообще есть.

Предприятие не режимное, случайно?

У меня информации нет. Но впечатление, что даже очень.

P.S. Это я к тому, что ежели режимное, то должны быть правила для передачи файлов. И можно запросто оказаться крайним при их нарушении.

У нас, как я написал выше, "своя" локальная сеть. К которой есть доступ только по одному каналу с одного фиксированного адреса (который в АРМе можно задать). Есть ли другие способы доступа, не знаю. Однако начальник сказал, что они потребовали, чтобы в нашей сети был RHEL, так как он сертифицировано на безопасность. И передача файлов должна идти по защищённому каналу.

[Hephaestus]

Их локальная сеть скорее "наша".

Тогда странно, что Вы не имеете информации. Хотя бы в общем виде: режимная ли контора, насколько закручены гайки.

Однако начальник сказал, что они потребовали, чтобы в нашей сети был RHEL, так как он сертифицировано на безопасность.

Это они уже потом потребовали? Спустя много времени? Или это сразу было?

И передача файлов должна идти по защищённому каналу.

Которого нет, насколько я понимаю. Ну, раз нет, надо организовать.
Мы вот организовывали в своё время. Но у нас была головная контора и филиалы - всё в пределах региона, когда затевали всю эту безопасность, человек из головной конторы приезжал лично.

Может, я чего не понимаю, но вроде бы первоначальный обмен ключами должен быть "из рук в руки".
А как это организовать, когда все "очень далеко", я не знаю.

[MiK13]

Их локальная сеть скорее "наша".

Тогда странно, что Вы не имеете информации. Хотя бы в общем виде: режимная ли контора, насколько закручены гайки.

Это другая страна. Я в командировки не ездил. Даже паспорт свой ещё не обновлял. "Контора" там, скорее всего, режимная. Просто так попасть туда нельзя. Когда люди были в командировке, они могли принимать от меня файлы только будучи в гостинице.

Однако начальник сказал, что они потребовали, чтобы в нашей сети был RHEL, так как он сертифицировано на безопасность.

Это они уже потом потребовали? Спустя много времени? Или это сразу было?

Очень похоже, что это не основной заказчик. То, что делаем мы, только часть. Они потом передают другим.
Сначала мы использовали Debian. Но потом они сказали, что нужен RHEL. Причём, 64-битный.
И из-за этого возникла проблема, которую я пока решить не могу.

И передача файлов должна идти по защищённому каналу.

Которого нет, насколько я понимаю. Ну, раз нет, надо организовать.
Мы вот организовывали в своё время. Но у нас была головная контора и филиалы - всё в пределах региона, когда затевали всю эту безопасность, человек из головной конторы приезжал лично.

У нас ничего подобного не было.
Некоторая часть информации, которая поступает на АРМы, должна, если разрешено, поступать на ещё один узел. Для этого я сделал скрипт, который (при разрешении), добавляет командой route add путь к определённому IP адресу через определённый интерфейс. И запускает на этот адрес:порт передачу нужных данных.
Кроме того, они сказали, что нужно иметь возможность забирать некоторые протоколы работы (с того же узла). Сначала я использовал vsftp. Но начальник сказал, что FTP нельзя, нужно что-то защищённое. И я тогда сказал, что, так как есть ssh-сервер, то по нему можно и по SFTP забирать. Вроде это устроило.

Может, я чего не понимаю, но вроде бы первоначальный обмен ключами должен быть "из рук в руки".
А как это организовать, когда все "очень далеко", я не знаю.

Как я понимаю, первоначально идёт обмен ключами для кодирования информации. А ключи для декодирования (другие) никуда не передаются. Поэтому передача "из рук в руки" не обязательна. Нужно первоначально только подтвердить доверие ключу для кодирования.
И от нас, НЯЗ, не требовали обеспечить обмен информацией. Требовали только предоставить возможность доступа.

[devilr]

MiK13
А вам не кажется, что "отсюда" эту задачу нельзя решить принципиально? Вариантов "перекинуть файл" ведь 100500 и все они могут разбиться о ту же режимность. Не зная точно, что там у вас есть, можно долго гадать, как именно можно сделать нужное.
Я бы просто обратился к безопаснику того объекта. Письменно.

[Hephaestus]

Но начальник сказал, что FTP нельзя, нужно что-то защищённое. И я тогда сказал, что, так как есть ssh-сервер, то по нему можно и по SFTP забирать. Вроде это устроило.

Так это позволяет Вам передать клиенту свои обновления или нет?

Как я понимаю, первоначально идёт обмен ключами для кодирования информации. А ключи для декодирования (другие) никуда не передаются. Поэтому передача "из рук в руки" не обязательна.

Разве? Мы с Вами обмениваемся ключами: Вы мне Ваш открытый, я Вам - мой открытый.
Если это не сделать лично "из рук в руки", а, переслать каким-то другим способом (например, по эл. почте), то откуда известно, что к Вам прилетел мой настоящий ключ? С "человеком посередине" что делать будем?
Понятно, что вероятность подмены близка к нулю.
Это надо целенаправленно следить за перепиской, потом подделать адрес отправителя, плюс может использоваться запароленый архив, а пароль можно передать по другому каналу связи (например, голосом по телефону)...
Ну, то есть теоретически подмена возможна, на практике - это не так просто.
Но на то она и безопасность, чтобы не исключать и теоретические возможности тоже.

Другое дело, когда ключи - это сертификаты, выданные УЦ. Эти да - можно пересылать без опасений.
Но в случае какого-нибудь "собственного ssh" этого как раз нет.

И от нас, НЯЗ, не требовали обеспечить обмен информацией.

Не понял. А это

передача файлов должна идти по защищённому каналу.

не обмен информацией?

[devilr]

Если это не сделать лично "из рук в руки", а, переслать каким-то другим способом (например, по эл. почте), то откуда известно, что к Вам прилетел мой настоящий ключ? С "человеком посередине" что делать будем?

Можно позвонить по телефону и попросить продиктовать последние N символов ключа. И так же голосом передать свои символы. Или положить оба ключа на сторонний ресурс, доступный обоим сторонам. Примитивно, но вполне работает.

[Hephaestus]

Можно позвонить по телефону и попросить продиктовать последние N символов ключа. И так же голосом передать свои символы.

Можно. Но в УЦ, например, тоже можно сгенерить ключ в ЛК на сайте и получить сертификат (типа ехать никуда не надо). Однако отпечаток ключа всё равно дается на бумажном носителе с подписью и печатью. То есть, несмотря на все онлайн-сервисы всё равно всё сводится к личному контакту. Наверно, неспроста.

Или положить оба ключа на сторонний ресурс, доступный обоим сторонам.

С этим хуже. Если злоумышленник притворился кем надо, он свой ключ и подсунет.
Впрочем, я сказал выше, что атака возможна в теории, а на практике всё несколько сложнее (надо очень умело притворяться и быть уверенным, что не раскроют), но тем не менее без личного контакта пока ещё не обходятся.

[devilr]

Если злоумышленник притворился кем надо, он свой ключ и подсунет.

Это как? Если вы глазами видите свой ключ и другая сторона также видит свой - что (и куда) злодей сможет "подсунуть"? Если только в ваши трафики залезет с ногами.

[Bizdelnick]

Но в УЦ, например, тоже можно сгенерить ключ в ЛК на сайте и получить сертификат (типа ехать никуда не надо). Однако отпечаток ключа всё равно дается на бумажном носителе с подписью и печатью.

Что за бред? Сертификат заверяется подписью УЦ, никаких бумажек к нему не надо.

[Hephaestus]

Что за бред? Сертификат заверяется подписью УЦ, никаких бумажек к нему не надо.

Мы ежегодно покупаем лицензию на КриптоПро и ежегодно же обновляем/заменяем ключи на носителях рутокен. Не поручусь, что каждый раз, но по крайней мере, один раз видел своими глазами. Бланк на листе формата А4 с отпечатком ключа и всякими подписями/печатями. Как раз для сверки, что с ключевой парой всё в порядке. То же самое было на моей предыдущей работе когда получали ключи уже не помню для чего. Контур-экстерн что ли.

[Bizdelnick]

рутокен

Контур-экстерн

Возможно, особенности отечественной бюрократии, но это полностью лишено смысла.

[devilr]

Бланк на листе формата А4 с отпечатком ключа и всякими подписями/печатями.

Это больше для бухгалтерии. Для вопросов, типа: "за что бабосики отвалили?". Поменять рубли на бумагу всё таки лучше, чем рубли на байты. Та же самая проблема, что и "linux на предприятиях" - нужен материальный носитель. Чтобы прикрепить его степлером.

[Hephaestus]

Это как? Если вы глазами видите свой ключ и другая сторона также видит свой

Возможно, я Вас не так понял.

положить оба ключа на сторонний ресурс, доступный обоим сторонам.

Я положил на общий ресурс мой открытый ключ. Вы его должны забрать.
Вы положили Ваш ключ, который я должен забрать.
Откуда мы знаем, что этот сторонний ресурс не доступен третьей стороне?
Если злоумышленник имеет доступ к этому же ресурсу, он положит свой, под видом, что это Ваш.
В этом же и есть суть идеи "человек посередине", не так ли?
Если ключ, не подписан УЦ, черт его разберет, подлинный ключ или нет.

[Bizdelnick]

Если ключ, не подписан УЦ, черт его разберет, подлинный ключ или нет.

Так можно ведь и подписать.

[devilr]

Если злоумышленник имеет доступ к этому же ресурсу, он положит свой, под видом, что это Ваш.

Ну так я то смогу проверить, мой это ключ или вражеский. Не хотите глазами смотреть - посчитайте для него контрольную сумму.
Ведь в этом и смысл пары ключей, что, имея ОТКРЫТЫЙ канал данных, обменяться ими. Я всегда могу проверить - мой это открытый ключ или уже подменённый. И другая сторона так же может проверить СВОЙ открытый ключ. Без всяких подписей.

[Hephaestus]

Возможно, особенности отечественной бюрократии, но это полностью лишено смысла.

Не совсем лишено. Бумага дана для сверки, что ничего не повреждено/подменено.
Хотя, возможно, это только в том случае, когда контора выдает готовый носитель.
Когда клиент сам генерит ключи через сайт, бумажек, наверно и нет. Но это я не знаю.

Ну и с криптопровайдерами примерно такая же история: там проверочные утилиты и тоже куча бумажек - формуляры. Хотя дистр вполне доступен для скачивания (приобретается только лицензия и этот вот формруляр). Инструкция предписывает проверить дистр, определенные файлы. И это тоже подкрепляется бумагой с напечатанными хешами. По криптопровайдерам - это всё касается сертифицированных решений - там много бумажек - они отдельно поставляются на диске. Это заморочки не столько бюрократии, сколько требований безопасности. Там же после установки всего этого хозяйства никакие изменения в системе не допустимы без регистрации. И журнал ведется бумажный. Глядишь на все эти требования и сразу хочется уйти на пенсию.

Добавлено (21:30):

Так можно ведь и подписать.

Можно. Но это для больших контор.
А вот захотел бы я иметь какой-нибудь токен с квалифицированной подписью, скажем, для полноценного использования каких-нибудь госуслуг или передачи документов - дороговато получается, оно мне не так часто нужно.

Ну так я то смогу проверить, мой это ключ или вражеский.

Вы-то можете проверить, что Ваш - это Ваш.
А как я проверю, что Ваш - это Ваш, и вообще что Вы - это Вы?
И как Вы проверите, что я - это я?

[devilr]

И как Вы проверите, что я - это я?

Голосом позвоню. И спрошу кличку "Васьки, с которым вы сидели за одной партой". Как пример.

А как я проверю, что Ваш - это Ваш, и вообще что Вы - это Вы?

А вам и не надо проверять мой ключ. Вам важно, чтобы ваш открытый ключ не подменили.
Если хотите, могу принципы расписать на примере Алисы и Боба, которые хотят встречаться, но так, чтобы об этом не знали их родители. И которые, как раз скомпрометировали их канал связи.

[Bizdelnick]

Бумага дана для сверки, что ничего не повреждено/подменено.

Вы что, без этого не знаете, какой ключ давали на подпись?

Когда клиент сам генерит ключи через сайт, бумажек, наверно и нет. Но это я не знаю.

Что? Ключи всегда должен генерить сам клиент. И не «через сайт», а локально. У УЦ приватного ключа быть не должно ни при какой погоде. К нему отправляется CSR с открытым ключом.

Инструкция предписывает проверить дистр, определенные файлы. И это тоже подкрепляется бумагой с напечатанными хешами. По криптопровайдерам - это всё касается сертифицированных решений - там много бумажек - они отдельно поставляются на диске. Это заморочки не столько бюрократии, сколько требований безопасности.

Да нет, это заморочки именно бюрократии. Для безопасности более чем достаточно списка в электронном виде, заверенного ЭЦП. Более того, возня с бумажками как раз очень небезопасна, потому что никто ж не станет сверять все цифры контрольных сумм глазами.

Можно. Но это для больших контор.

Что для больших контор? OpenSSL и OpenSSH?

[MiK13]

И от нас, НЯЗ, не требовали обеспечить обмен информацией.

Не понял. А это

передача файлов должна идти по защищённому каналу.

не обмен информацией?

Я не знаю всех подробностей контракта. Но у меня впечатление, что то, что мы даём заказчику, является какой-то частью большой системы. И он сам является исполнителем для другого заказчика.
Это не первый договор. И сначала не было никаких возражений по поводу Debian. Для меня это сейчас наиболее удобная система.
Но потом, вдруг, начальник заявляет, что "Debian не годится, нужен Red Hat". Да ещё с серьёзной проверкой на безопасность.
Сначала система делалась как замкнутая. Потом оказалось, что надо "наверх" отдавать некоторую информацию. Я это реализовал. С возможностью подключения с определённого IP адреса на определённый интерфейс. И это разрешается (и запрещается) оператором АРМа.
Потом сказали, что нужна возможность забирать файлы протоколов. Я поставил vsftpd и добавил пользователя с простым паролем. И с ограничением доступа к каталогу с протоколами.
А потом появилось требование "Red Hat и максимальная секретность". И начальник сказал: "FTP НИЗЯ! Нужно SFTP".
Смысла я не понимаю. Но, как "старый попугай крикнул из ветвей..."
А что касается "Человека в середине", Метод старый, ещё Александр Сергеевич про него писал.
Но в нашем случае я пока не могу представить другой вариант, как прийти с ноутбуком с двумя интерфейсами и кабелем, вынуть кабель из разъёма, вставить его в свой ноутбук, А другим разъёмом соединить ноутбук с АРМом.

[Hephaestus]

Голосом позвоню. И спрошу кличку "Васьки, с которым вы сидели за одной партой".

В том-то и дело. При дистанционном обмене ключами нужна дополнительная проверка.
Я ровно об этом и говорил. Ну или это должен быть сертификат, подписанный УЦ.

Вам важно, чтобы ваш открытый ключ не подменили.

Это Вам важно. У меня мой подлинный ключ и так есть.
А вот у Вас моего открытого ключа пока нет, Вы должны его забрать с общего ресурса.
Вот тут-то Вам и нужно убедиться, что Вы забрали именно мой ключ, а не подмененный.
А меня, соответственно, интересует подлинность Вашего ключа.
И вот убедиться в подлинности ключа, который не заверен УЦ... без дополнительных проверок невозможно.
Потому я и говорю: если есть возможность передать "из рук в руки", то лучше так и сделать. Чтобы уж без сомнений.

Вы что, без этого не знаете, какой ключ давали на подпись?

Когда получаем готовый токен, то, в общем, не знаем, всё ли там нормально записалось.

Что? Ключи всегда должен генерить сам клиент. И не «через сайт», а локально. У УЦ приватного ключа быть не должно ни при какой погоде.

Вашими бы устами...
Я когда-то рассказывал уже. Затеяли как-то раз обмен с банком по поводу зарплаты (бухгалтерия должна была передавать файл реестра, подписанный цифровой подписью). Банк предоставляет свою софтину.
Присылают, значит, мне всё это хозяйство, а там пара ключей. Это чего? Не понял.
Звоню туда.
Примерно такой диалог:
- Закрытый ключ вроде должен быть только у меня.
- Да. Ну, мы сами генерим ключи и отдаем клиенту всё сразу. Клиентам так проще.
- А можно, я сам создам ключевую пару и привезу Вам ключ?
- Хорошо. Приезжайте. Жду Вас.

Создаю ключевую пару, беру открытый ключ, приезжаю в банк.
Отдаю им ключ, они говорят: Вы первый человек, который сделал, как положено.
Вот так-то. И это банк. А уж при изготовлении токенов такое вообще сплошь и рядом.

Что для больших контор?

Услуги УЦ для больших контор.
У нас сменилась газовая компания. Нужно переоформить договор.
Дело довольно хлопотное, народу много, в рабочие часы просто физически не успеть.
Они на сайте предлагают дистанционный вариант: все документы прислать в эл. виде,
но они должны быть заверены квалифицированной ЦП.
Я сунулся, посмотрел.
Для физического лица квалифицированная подпись порядка 3000 руб., там разные варианты, есть за 5000 руб.
Вот прям щас все побегут себе цифровые подписи оформлять, угу. Проще сходить в офис и лично подписать договор.

То же самое с гос услугами: для получения доступа ко всем сервисам нужна квалифицированная подпись.
Ну, вот мне как физическому лицу за такую сумму оно нафиг не нужно.

[MiK13]

Задачу в принципе решили.
Связались по телефону и попросили их поставить TeanViewer. Затем поставили PuTTY.
Теперь после связи по телефону (или скайпу) подключаемся к их компьютеру с Windows 10. Определяем его IP адрес (например, 192.168.mmm.nn0), просим их зайти на АРМ под сервисным именем, вызвать терминал и дать выдать несколько команд:
sudo su
ifconfig enp3s0 192.168.mmm.nn1 # nn1 обычно nn0+1, проверяем, чтобы не пинговался
route add 192.168.mmm.nn0
После этого через PuTTY подключаемся к АРМу.
Правда, почему-то не получилось пересылать файлы через pscp.exe, но через psftp.exe получилось.
Правда, как работает АРМ и какие в нём возникают проблемы мы может проверить только на экране смартфона через Skype.

Кстати, нет ли для Windows какого-нибудь X-сервера, чтобы можно было через тимвьювер от нас проверять работу АРМа?

[Bizdelnick]

TeanViewer

Skype

Безопасность на высоте.

нет ли для Windows какого-нибудь X-сервера

Был какой-то Xming, кажется.