Проблема доступа к клиенту, когда сервера могут инициализировать соединение с клиентом, а клиент с ними нет, обычно разрешается с помощью «реверса» клиентов, при котором клиенты ожидают появления серверов для того, чтобы установить с ними соединение и послать им данные в стиле X-Windows. И действительно, слишком часто кто-то открыто запрашивает режим клиента SSH, для того чтобы разрешить программе sshd подключиться к нему. Подобные решения, если только они с самого начала не были заложены в протокол и его реализацию, в лучшем случае дезинформируют, а в худшем -ужасно небезопасны. Применение для перенаправления SSHD переадресации удаленного порта вместо доступа к Web-сети является уникальным расширением хорошо устанавливаемых и в общем-то безопасных методологий, которые постоянно используются. Внедрение редко используемого клиента в sshd и сервера в ssh является слишком специфичным и совсем необязательным бедствием, которое только выжидает удобный момент для своего свершения.

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

Эхо на чуждом языке: перекрестное соединение взаимно защищенных межсетевыми экранами хостов

Типовое использование протокола передачи файлов FTP для управления защищенными межсетевыми экранами сетями предусматривает наличие хостов, которые не могут получить соединение и всегда генерируют поток выходящих данных к хосту, который может их получить. (Характеризуя протокол FTP, можно сказать, что, по крайней мере, это несколько странный протокол. Для сохранности своих соединений, упорядоченных в том же самом направлении, необходимо перевести протокол в так называемый пассивный режим (Passive Mode). Пассивный режим протокола FTP предусматривает, что сервер сообщает клиенту номер порта, по которому в случае установления соединения клиент передаст содержимое файла. Напротив, работа в активном режиме (Active Mode) ориентирована на клиента, который ранее инициировал выходящее соединение к серверу и сейчас посылает запрос к серверу для установки сервером выходящего соединения обратно к клиенту по некоторому случайному порту, для того чтобы разместить переданный сервером файл. Межсетевым экранам было сложно работать с одним из грандов старых протоколов Интернета из-за того, что приходилось выполнять сложную подстройку протокола FTP в результате непредсказуемых изменений направлений соединений и номеров портов.) В

инструментариях Napster и Gnutella реализованы системы, которые автоматически выясняют, какая из сторон транзакции не может получать запросы на соединение. После чего транзакция создает TCP-соединение, а дальше файл либо проталкивается в канал связи (командой PUT), либо выталкивается из него (командой GET) на хост, который выдал запрос на пересылку файла.

Все хорошо работает в случае, когда одна или другая сторона может получать запросы подключения. Но что произойдет, если ни одна из сторон не сможет этого сделать? Что, если оба хоста расположены позади домашних маршрутизаторов, которые поддерживают возможность сетевой трансляции адресов NAT и им даже присвоены те же самые личные IP-адреса? Еще хуже. Что произойдет, если оба хоста работают за уровнем ядра корпоративного межсетевого экрана Cisco и возникает критическая потребность в интересах дела предоставить двум хостам возможность обмениваться информацией? Как правило, в данном случае усилия администраторов штабов информационных технологий обоих хостов будут направлены на то, чтобы один хост нашел брешь в системе защиты своего межсетевого экрана, что позволило бы другому хосту связаться с первым. Поскольку обязательно произойдет так, что самые параноидные члены штаба информационных технологий настраивают межсетевой экран и управляют им, то в результате будет получен нелепо медленный и болезненный процесс, абсолютно неприемлемый на практике, если только потребность в нем не окажется бесспорной и, возможно, постоянной.

Иногда возможно более изящное решение. Основная идея универсального решения, которое может быть использовано в случае отсутствия непосредственного сетевого соединения, заключается в использовании третьего хоста, так называемого отражателя подключения (connection bouncer). Отражатель подключения получает исходящие от обоих хостов соединения и затем рикошетом отправляет трафик с первого хоста на второй и наоборот.

Приоткрывая завесу

Квитирование установления связи: всего лишь брокер подключения

Рикошет всего соединения может стать причиной превращения отражателя подключений в опасное узкое место, потому что в любом направлении он должен видеть весь трафик дважды: один раз - при получении пакетов и еще один раз - при отсылке их обратно. По этой причине интерес к отражателю подключений отсутствует даже со стороны наиболее амбициозных проектов соединения равноправных узлов хостов P2P (peer-to-peer -соединение равноправных хостов (узлов)). Существуют сугубо экспериментальные системы, которые позволяют находящимся посередине соединения хостам запросто становиться брокером подключения (broker the connection). Брокеры подключения предоставляют двум хостам, запрашивающим выходящие линии связи, средства склеивания друг с другом. Подобные методы описаны в конце главы 12 и их полная работоспособность везде и всегда не гарантируется (авторы разработали их только во время написания книги). Напротив, приведенные ниже методы более работоспособны и надежны.

В общем случае проксисервера являются разновидностью отражателя подключения. Запрос на выходящее соединение перенаправляется по направлению отсылки ответного сигнала входящего соединения от удаленного Web-cepeepa или что-то в этом роде. В данном случае это не всегда полезно. Существуют небольшие приложения, которые делают из сервера отражатель подключения, но логика их работы слегка запутана, и они не всегда переносимы. Кроме того, почти всегда они не поддерживают криптографических возможностей, которые пусть не всегда нужны, но полезно, когда они есть под рукой.

К счастью, в данном случае нет необходимости ни в том, ни в другом. Если читатель вспомнит, то сначала была описана система с клиентом, который не мог непосредственно инициировать соединение с сервером. Вместо этого для создания сквозной безопасной линии связи по протоколу SSH клиент подтверждал свою подлинность хосту-бастиону и использовал сетевой путь, доступный ему благодаря бастиону. Затем была описана система, в которой для подключения клиента хост-бастион уже не предусматривался. Сервер самостоятельно инициировал свое собственное соединение с внешним миром, экспортируя при помощи переадресации удаленного порта путь клиенту для того, чтобы он проложил к нему обратный туннель. Так получилось, что этот путь был экспортирован непосредственно клиенту, хотя в этом не было необходимости. На самом деле сервер мог бы использовать переадресацию удаленного порта своему собственному SSH-демону на любом хосте, который был бы доступен как серверу, так и клиенту. После этого клиенту было бы достаточно просто обратиться к этому доступному как со стороны сервера, так и со стороны клиента хосту, который внезапно стал хостом-бастионом. Ниже рассмотрено объединение двух названных методов в один:

# Server: Export link to a mutually accessible “floating # bastion server”

[effugas@localhost effugas]$ ssh -R20022:127.0.0.1:22 effugas@10.0.1.11

effugas@ 10.0.1.11 ’ s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $
# Client: Import link from the mutually accessible
# “floating bastion server” (not using netcat,
# because we’re assuming zero software installation
# for this host) effugas@OTHERSHOE ~

$ ssh -L30022:127.0.0.1:20022 effugas@10.0.1.11 effugas@ 10.0.1.11 ’ s password:

FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $
# Client: Initiate a connection over the imported/
# exported link, verifying the endpoint goes where we
# think it does. effugas@OTHERSHOE ~
$ ssh -o HostKeyAlias= 10.0.1.10 -p 30022 effugas@ 127.0.0.1 Enter passphrase for key “/home/effugas/.ssh/id_dsa”:
Last login: Mon Jan 14 12:00:19 2002 from 10.0.1.56 [effugas@localhost effugas]$

На полпути: что теперь?

После блуждания в поисках достижения поставленной цели читатель наконец обнаружит себя в конечной точке, к которой он все это время предпринимал попытки проложить туннель. И что, считать теперь спорный вопрос решенным? Другими словами, уместно спросить: «Что теперь?» Конечно, читатель может администрировать все, что ему нужно, пользуясь удаленной командной оболочкой. Он может подключиться к различным хостам, которые могут предоставить читателю точки сетевого доступа к необходимым ему ресурсам. Но протокол SSH предлагает нечто большее, особенно когда используется переадресация команд. Наиболее важный вывод этой главы состоит в том, что все рассмотренные в ней методы могут быть успешно сведены в единую цепочку. Ниже приведены примеры, которые показывают, каким образом ранее описанные способы могут быть соединены вместе точно так же, как и строительные кубики в конструкторе LEGO, способствуя появлению новых и интересных способов.

Стандартная передача файла при помощи протокола SSH

Стандартным инструментальным средством копирования файлов внутри SSH-туннеля является программа Secure Copy (scp). Ее общепринятый базовый синтаксис весьма близок к синтаксису команды ср. Путь на удаленную машину определяется обычным образом:

user@host:/path. Ниже приведен пример копирования локального файла dhcp.figure.pdf в директорию /tmp, расположенную на удаленном хосте 10.0.1.11:

dan@OTHERSHOE ~ $ scp dhcp.figure.pdf dan@10.0.1.11:/tmp
dan@10.0.1.11”s password:
dhcp figure pdf 100% ^766 00*00

При копировании директории следует задать флажок -г, что очень похоже на формат команды ср. При копировании опция -г указывает на необходимость рекурсивного просмотра всего дерева директории сверху вниз. Программа scp сделана по образцу команды гср и выполняет все, что необходимо, но если честно, то не очень хорошо. Ошибочная настройка путей часто является причиной аварийного завершения серверной части программы scp, а специфицировать опции командной строки ssh нереально. Сказанное не означает невозможности воспользоваться некоторыми наиболее интересными системами туннелирования. Программа scp предоставляет возможность повторной настройки ssh посредством более многословного интерфейса файла конфигурации. Читатель, введя man ssh, может найти полный список настраиваемых опций. Ниже показан пример спецификации опции HostKeyAlias, позволяющей проверить адресата локального переадресованного порта SSH:

# setting up the tunnel: Local port 2022 is routed to port # 22(ssh) on 10.0.1.10, through the bastion host of
# 10.0.1.11
dan@OTHERSHOE ~

$ ssh -L2022:10.0.1.10:22 dan@10.0.1.11

dan@10.0.1.11’s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $
# Copy a file through the local port forward on port 2022,
# and verify we’re ending up at 10.0.1.10. dan@OTHERSHOE ~
$ scp -o “HostKeyAlias 10.0.1.10” -o “Port 2022” dhcp.figure.pdf
root@ 127.0.0.1 :/tmp root@127.0.0.1’s password:
dhcp figure pdf 100% ^766 00*00

В результате был получен доступ с правами суперпользователя к хосту с IP-адресом 10.0.1.10, который был связан по каналу с хостом 10.0.1.11. Что произойдет, если хост 10.0.1.11 вместо оказания должного уважения команде, которая перенаправляет пакеты к демону другого SSH-хоста, перешлет их к собственному хосту? Другими словами, что произойдет, если в результате повреждения сервера он начнет работать так, как если бы была указана опция - L2022:127.0.0.1:22 вместо L2022:10.0.1.10:22? Давайте попробуем так сделать:

dan@OTHERSHOE ~ $ ssh -L2022:127.0.0.1:22 dan@10.0.1.11

dan@10.0.1.11’s password:
FreeBSD 4.3-RELEASE (CURRENT-12-2-01) #1: Mon Dec 3 13:44:59 GMT 2001 $
dan@OTHERSHOE ~
$ scp -o “HostKeyAlias 10.0.1.10” -o “Port 2022” dhcp.figure.pdf
root@ 127.0.0.1 :/tmp
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-themiddle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is 6b:77:c8:4f:el:ce:ab:cd:30:b2:70:20:2e:64:ll:db.
Please contact your system administrator.
Add correct host key in /home/dan/.ssh/known_hosts2 to get rid of this message.
Offending key in /home/dan/.ssh/known_hosts2:3 RSA host key for 10.0.1.10 has changed and you have requested strict checking, lost connection

Комментируя описанное, следует обратить внимание читателя на одно важное замечание. Очень важно управлять ключами идентификации (identity keys) протокола SSH! Хотя бы только потому, что правильный ключ помещается в файл known_hosts2. Прежде всего он записывается туда для того, чтобы была возможность различать ответивший демон SSH: был ли прислан ответ при обмене данными с правильным хостом или ответ был получен во время обмена данными с неверным хостом? Одним из самых больших недостатков протокола SSH является то, что благодаря некоторым особенностям обновления серверов они постоянно изменяют свои идентификационные ключи. Это вынуждает пользователей смириться с любыми изменениями в ключах, даже если автором изменений станет атакующий. Dug Song воспользовалась доступной для использования ловушкой в своем великолепном пакете dsniff, предназначенном для перехвата, анализа и прослушивания трафика. Пакет dsniff доступен по адресу www.monkey.org/~dugsong/dsniff/. Он демонстрирует, с какой легкостью пользователь может воспользоваться различными трюками для одурачивания сессии SSH1 в результате получения им возможности стать «обезьянкой посередине» («monkey in the middle»). Инкрементная передача файла по протоколу SSH

Несмотря на то что программа rsync является всего лишь стандартной компонентой стандартного окружения большинства систем UNIX, она является наиболее уважаемой порцией программного кода среди созвездия программ с открытыми исходными текстами. По существу, rsync относится к классу программ обновления файлов по шагам с нарастающим итогом. Клиент и сервер обмениваются небольшими порциями итоговых данных о содержимом совместно используемого ими файла. При этом определяются блоки, требующие обновления, а затем только они и пересылаются. Если после последнего выполнения программы rsync изменились только 5 Мб 10-гигабайтного диска, то полная пропускная способность канала обмена данными между клиентом и сервером, затрачиваемая на их синхронизацию, будет всего лишь немного больше пяти мегов (megs).

Программу rsync можно найти по адресу http://rsync.samba.org, что неудивительно, поскольку считается, что ее автор Андрей Тридгель (Andrew Tridgell) также принимал активное участие в подготовке и начале реализации проекта Samba, в рамках которого решалась задача совместного использования файлов Windows машинами UNIX.

Описанная программа проста в использовании, особенно совместно с ssh. Базовый синтаксис инструментария очень похож на scp:

dan@OTHERSHOE ~ $ rsync -е ssh dhcp.figure.pdf dan@10.0.1.11:/tmp dan@10.0.1.H’s password:

В отличие от scp, по умолчанию программа rsync более молчалива. Использование флажка -v позволяет получить больше отладочных выходных данных. Как и в случае с scp, флажок -г необходим для задания копирования деревьев директорий. На сканирование директорий требуется время, что приводит к значительной задержке перед началом собственно копирования. Особенно это касается платформы Windows. У программы rsync более удачный синтаксис для использования дополнительных разновидностей транспортировки данных по протоколу ssh. Опция - е непосредственно определяет использование командной строки для удаленного выполнения команды. Для того чтобы использовать не только протокол SSH, но и протокол SSH1, достаточно воспользоваться следующей командой:

dan@OTHERSHOE ~ $ rsync -е “ssh -1” dhcp.figure.pdf dan@10.0.1.11:/tmp dan@10.0.1.H’s password:

Программа rsync является необычайно эффективным методом предотвращения избыточного трафика. Она может оказаться особенно полезной для эффективного обновления динамически изменяющихся данных, которое можно регулярно наблюдать на Web-сайтах. Новейшая компонента гргоху Мартина Пула (Martin Pool) непревзойденного Sweetcode (www.Sweetcode.org) является интересной попыткой миграции протокола работы rsync непосредственно в протокол HTTP. Это хорошая идея, к тому же изящно и эффективно реализованная. Мартин приводит следующие данные: «Ранние реализации гргоху позволяют достигнуть сохранения пропускной способности для порталов Web-сайтов на уровне 90 %». Это немаловажно и определенным образом выравнивает дополнительную обработку загрузки новых данных. Хотя еще предстоит выяснить, насколько успешными окажутся эти усилия, но уже сейчас ясно, что rsync через программу httptunnel и протокол SSH работает вполне прилично. (Еще раз напомним читателю, что программа httptunnel доступна благодаря nocrew. Ее можно найти по адресу www.nocrew. org/software/httptunnel.html.) Остроумным решением является следующее. Запустите серверную часть программы httptunnel:

[effugas@localhost effugas]$ hts 10080 -F 127.0.0.1:22 Запустите клиентскую часть программы httptunnel:

effugas@OTHERSHOE ~/.ssh $ htc -F 10022-P 10.0.1.11:8888 10.0.1.10:10080 Покажем, какие файлы скопируются после попытки скопировать их с использованием опции -v:

dan@OTHERSHOE ~ $ rsync -v -г -е “ssh -о HostKeyAlias=10.0.1.10 -о Port=10022” stuff/dan@127.0.0.1 :/tmp

dan@10.0.1.H’s password: building file list... done doxscan_0.4a.tar.gz fping-2.4b2.tar.gz lf.tar.gz

Инструментарий и ловушки Улучшение производительности SSH

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

• при использовании опции - С включается режим сжатия. За счет некоторых затрат процессорного времени и, вероятно, некоторой задержки SSH может воспользоваться программой zlib для сжатия данных. В результате скорость обработки многих видов трафика может быть значительно увеличена;

• применив опцию шифрования - с, можно поменять используемые симметричные криптографические алгоритмы. Алгоритм тройной DES обладает многими достоинствами, но его эффективность даже отдаленно не принадлежит к их числу. По умолчанию для 88Н2-подключений будет использоваться алгоритм AES128-cbc - 128-битный алгоритм AES в режиме сцепленных блоков шифрования (cipher block chaining mode). Общепризнанно, что этому алгоритму можно доверять в той же степени, что и алгоритму тройного DES. Алгоритмы blowfish и особенно arcfour являются гораздо более быстрыми алгоритмами, причем их работа предусмотрена как в протоколе SSH1, так и в протоколе SSH2;

• используя опцию -1, можно получить снижение эффективности применения протокола SSH1. Честно говоря, использовать эту опцию не рекомендуется, но все же это лучше передачи открытого текста по каналу связи;

• очевидно, чем больше будет случаев взлома сетевых программ сетевого взаимодействия компьютеров, тем медленнее будет работать система. Зачастую полезно использовать SSH как метод решения известной проблемы «цыпленка и яйца», которая относится к явлениям, где трудно определить причину и следствие. Применительно к рассматриваемому случаю это означает отсутствие изменений до тех пор, пока отображается результат, но результат не может быть отображен до тех пор, пока не будут завершены изменения. В случае взлома во время использования SSH (назовем это доказательством идеи и ничем более) результирующая величина может быть показана и изменения санкционированы.

Запись на компакт-диск по протоколу SSH

Стандартный метод записи последовательности локальных файлов, используемый в операционных системах UNIX, предусматривает использование двух программ. Сначала одна из них, mkisofs, вызывается для упаковки записываемых файлов в стандартную файловую систему, понятную для CD-ROM. Другим словами, она создает файловую систему в формате IS09660. Затем результат упаковки (файлы в ISO-формате) пересылаются другому приложению, cdrecord, который выполняет запись файлов на CD-ROM (прожиг файлов). Полная процедура описанных действий выглядит следующим образом.

Сначала ищется и обнаруживается устройство записи на компакт-диск SCSI-ID, которое планируется использовать:

bash-2.05a# cdrecord -scanbus Cdrecord 1.10 (i386-unknown-freebsd4.3) Copyright (С)

1995-
2001 Jorg Schilling
Using libscg version “schily-0.5”
scsibusO:
0,0,0 0) ‘PLEXTOR ’ ‘CD-ROM PX-40TS ’ ‘1.11’
Removable CD-ROM
0,1,0 1) ‘YAMAHA’ ‘CRW2100S ’ ‘1.0H’
Removable CD-ROM
0,2,0 2) ‘YAMAHA’ ‘CDR400t ’ ‘l.Oq’
Removable CD-ROM
0,3,0 3) *

Затем для записи выбирается директория или набор файлов, которые пользователь собирается записать на компакт-диск. Приложение подключает к именам файлов атрибуты Joliet и Rock Ridge. В результате появляется возможность использовать длинные имена файлов, которые стандарт IS09660 поддерживает обычным образом. Часто бывает полезным при использовании программы mkisofs дополнительно указать опцию -/ следом за symlinks.

В следующем примере будет показано, как задуманное реализовать проще:

bash-2.05a# mkisofs -JR toburn/ > tools.iso 22.21% done, estimate finish Thu Jan 3 19:17:08 2002
44.42% done, estimate finish Thu Jan 3 19:17:08 2002
66.57% done, estimate finish Thu Jan 3 19:17:08 2002
88.78% done, estimate finish Thu Jan 3 19:17:08 2002
Total translation table size: 0
Total rockridge attributes bytes: 726
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used c064
22544 extents written (44 Mb)

Как читатель может заметить, после выполненных действий пользователь должен поскучать без дела, ожидая, пока область дискового пространства растрачивается понапрасну. Гораздо более изящное решение заключается в непосредственном перенаправлении вывода программы mkisofs на вход приложения cdrecord. И действительно, именно так в большинстве случаев реализован прожиг данных в операционной системе UNIX:

bash-2.05а # mkisofs -JR toburn/ cdrecord dev=0,l,0 speed=16 -

Cdrecord 1.10 (i386-unknown-freebsd4.3) Copyright (C) 1995-
2001 Jorg Schilling
scsidev: ‘0,1,0’
scsibus: 0 target: 1 lun: 0
Using libscg version ‘schily-0.5’
Device type : Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor_info: ‘YAMAHA ’
Identifikation : ‘CRW2100S ’
Revision : ‘1.0H’
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmccdr).
Driver flags : SWAB AUDIO
cdrecord: WARNING: Track size unknown. Data may not fit on disk.
Starting to write CD/DVD at speed 16 in write mode for single session.
Last chance to quit, starting real write in 9 seconds

Следует помнить одно важное правило. Оно заключается в том, что почти всегда, когда пользователь пожелает воспользоваться каналом для передачи данных между процессами, SSH позволит ему разместить процессы на разных хостах. Поскольку процессы создания файловой системы и ее записи отделены друг от друга, то можно создать файловую систему на одной машине, а записать ее на другой:

dan@OTHERSHOE ~ $ mkisofs.exe -JR backup/ ssh dan@10.0.1.11 “cdrecord

dev=0,l,0
speed=8 -”
dan@10.0.1.11’s password: scsidev: ‘0,1,0’ scsibus: 0 target: 1 lun: 0
Cdrecord 1.10 (i386-unknown-freebsd4.3) Copyright (C) 1995-
2001 Jorg Schilling
Using libscg version ‘schily-0.5’
Device type : Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor_info: ‘YAMAHA ’
Identifikation : ‘CRW2100S ’
Revision : ‘1.0H’
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmccdr).
Driver flags : SWAB AUDIO
cdrecord: WARNING: Track size unknown. Data may not fit on disk.
Starting to write CD/DVD at speed 8 in write mode for single session.
Last chance to quit, starting real write in 8 seconds

Быстродействие и надежность базовой архитектуры сети являются критичными параметрами для поддержки устойчивого процесса записи данных на CD-диск. Слишком большой период времени, в течение которого не производится обновление пересылаемого на диск содержимого, приводит к тому, что вовсе ничего не будет записано. В итоге пространство на диске будет потрачено впустую (если только устройство записи данных на компакт-диск не поддерживает новую и полезную технологию под названием Burn-Proof, которая в большинстве случаев позволяет избежать бесполезной траты дисковой памяти). Если необходимо записать данные на компакт-диск, пересылая их по медленной или ненадежной сети, то следует воспользоваться удобной возможностью протокола SSH удаленно выполнять не одну, а серию команд. В этом случае последовательность команд будет состоять из команд поиска ISO, записи найденных данных на компакт-диск и удаления уже ненужных данных. Используемое при этом форматирование преследует единственную цель: сделать текст команд удобочитаемым. Что действительно необходимо для выполнения многократных команд за одно обращение к SSH, так это использование между командами точки с запятой.

dan@OTHERSHOE ~ $ mkisofs.exe -JR backup/ ssh dan@10.0.1.11 \

> “cat > /tmp/burn.iso && \
> cdrecord dev=0,l,0 speed=8 /tmp/
> burn.iso && \
> rm /tmp/burn.iso” dan@10.0.1.11’s password:
Total translation table size: 0
Total rockridge attributes bytes: 2829
Total directory bytes: 0
Path table size(bytes): 10
Max brk space used 9000
3066 extents written (5 Mb)
scsidev: ‘0,1,0’
scsibus: 0 target: 1 lun: 0
Cdrecord 1.10 (i386-unknown-freebsd4.3) Copyright (C) 1995-
2001 Jorg
Schilling
Using libscg version ‘schily-0.5’
Device type : Removable CD-ROM Version: 2 Response Format: 2 Capabilities : SYNC Vendor info : ‘YAMAHA ’
Identifikation : ‘CRW2100S ’
Revision : ‘LOH’
Device seems to be: Generic mmc CD-RW.
Using generic SCSI-3/mmc CD-R driver (mmc cdr).
Driver flags : SWAB AUDIO
Starting to write CD/DVD at speed 8 in write mode for single
session.
Last chance to quit, starting real write in 8 seconds.

Переадресация динамического порта | Защита от хакеров корпоративных сетей | Акустический канал: передача аудиоданных с помощью протоколов tcp и ssh


Защита от хакеров корпоративных сетей



Новости за месяц

  • Август
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс