Несомненно, интерес представляет домашняя страница SSH http://www.ssh.fi/sshprotocols2.
Этот FAQ был создан на основе оригинального, устаревшего на данный момент FAQ
по SSH1 [SSH Protocol-1]:
http://www.un
i-karlsruhe.de/~ig25/ssh-faq/index.html
(написан Thomas.Koeni
g@ciw.uni-karlsruhe.de
)
Следующая Глава,
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы
Ssh (Secure Shell) это программа для входа в другие компьютеры доступные по сети, для выполнения команд или программ на удаленных компьютерах и для передачи файлов с одного компьютера на другой. Она обеспечивает строгую проверку подлинности и безопасности соединений по незащищенным каналам. И используется как замена rlogin, rsh, и rcp.
Дополнительно, ssh обеспечивает безопасность X-овых соединений и безопасное перенаправление иных, необходимых вам TCP соединений.
X Window System имеет тоже достаточное количество "узких" мест в плане безопасности. Но с помощью ssh можно создавать безопасные удаленные X-овые сеансы, которые будут также прозрачны для пользователя как и раньше. Сторонний - косвенный эффект использования ssh при запуске удаленных X-овых клиентских приложений это еще большая простота для пользователя.
При этом можно как и прежде использовать настройки в старых файлах .rhosts и /etc/hosts.equiv, ssh прекрасно их понимает. А если удаленная машина не поддерживает ssh, то сработает "обратный механизм" возврата к rsh, который включен в ssh.
Все вышесказанное ВЕРНО лишь при использовании шифрования. Однако Ssh имеет опцию шифрования "none", которая необходима лишь для отладки и ни в коем случае не должна быть использована для обычной работы.
Если какой-либо недоброжелатель имеет доступ в вашу домашнюю директорию то безопасность так же под вопросом, одной из частых тому причин является, например экспортирование домашней директории по NFS.
Все коммуникации шифруются с использованием метода IDEA или любым на выбор из следующих: three-key triple-DES, DES, Blowfish. Для обмена ключей шифрования используется RSA метод, данные обмена уничтожаются каждый час(ключи нигде не сохраняются).Каждая машина имеет свой RSA-ключ который используется для проверки достоверности машины при задействии метода "RSA host authentication". Шифрование используетс для предотвращения "IP-Spoofing"; проверка достоверности публичных ключей против "DNS и Routing Spoofing".
RSA-ключи используются для проверки достоверности компьютеров.
Эта статья также включает описание того как ssh работает:
Смотрите также секцию 3.7 Где можно получить помощь? содержащий различные ссылки на материалы в сети по SSH.Следующая Глава, Предыдущая Глава
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы
В настоящий момент Ssh работает на Unix-based платформах. И успешно портирован на все "ведущие" Unix ситемы.
В ходе переписки между "Data Fellows" и ведущим этого FAQ'а были заданы следующие вопросы и соответственно получены ответы:
===============================================================
Чтобы небыло претезий по переводу, оставлен оригинал:
S: Steve Acheson, FAQ
Maintainer
P: Petri Nyman, F-Secure
SSH Product Manager for Data Fellows
S>Can a company use the 1.2.26 release of the SSH software freely
for
S>internal support and administration without violating the license
S>agreement?
перевод
S>Может ли компания свободно использовать 1.2.26 реализацию SSH
S>в целях внутренней поддержки и администрирования не нарушая при этом
S>соглашения о лицензировании?
P>You can freely use it for internal support and administration
of your own
P>equipment located in your premises.
перевод
P>Вы лично можете свободно использовать для внутренней поддержки и
P>администрирования вашего собственного оборудования находящегося
P>в вашей собственности.
S>Does connecting from one machine to another via SSH to
S>read email, do work, etc, violate this agreement?
перевод
S>Нарушает ли соглашение соединение с одной машины на другу по SSH
S>для чтения почты, выполнения работы и тд и тп?
P>No, unless you provide this ability to a third party or connect
to a third
P>party's computer to provide a service.
перевод
P>Нет, в том случае если если вы для использования этих сервисов соединяетесь
P>с компьютерами _третьей_стороны_ или предоставляете сервис _третьей_стороне_.
S>Does connecting from a purchased PC client SSH software to a non-licensed
S>SSH server violate the agreement?
перевод
S>Нарушается ли соглашение если соединение установлено между клиентом
S>SSH имеющим лицензию и нелицензированным SSH сервером?
P>No.
перевод
P>Нет.
S>Does connecting to a remote site, that is not company owned, but
company
S>administered, via SSH to do administrative work violate the agreement?
перевод
S>Нарушается ли соглашение если устанавливается соединение с компьютером не принадлежащим
S>компании, но ею администрируется, с целью проведения административных работ.
P>Yes. You need a commercial license for that.
перевод
P>Да. Для таких целей необходимо приобрести лицензию.
===============================================================
Unix версии ssh 2.0.13 могут быть использованы ТОЛЬКО в случае персонального использования или в целях обучения (см. license agreement). В случае коммерческого использования необходимо купить лицензию у Data Fellows.
Более ранние версии ssh имеют менее ограниченную лицензию; читайте об этом в файле COPYING сопровождающем дистрибутив каждой версии.
В некоторых странах, особенно Франции, России, Ираке и Пакистане, вовсе запрещено использование шифрования без особого на то разрешения.
Если находитесь в USA, то должны осозновать что любая попытка экспортировать ssh за пределы штатов будет рассматриваться как уголовно-наказуемая, сюда же относится и попытка размещения на ftp серверах находящихся за пределами USA, не взирая на то что сам SSH был написан за пределами USA и с использованием лишь свободно доступных материалов. Для получения более полной информации обращайтесь в ведомство "Defence Trade Controls".
Алгоритмы RSA и IDEA, которые используются в ssh, имею самостоятельные патентные права в разных странах, включая US. Вместо них можно воспользоваться библиотекой RSAREF, однако законность использования в некомерческих целях ssh в US в таком случае, может восприниматься двояко. Вам может понадобиться приобретение лицензии для коммерческого использования IDEA; однако ssh будет прекрасно работать будучи сконфигурирован и без него.
Для более подробной информации читайте файл COPYING из дистрибутива ssh.
Использование версии ssh 2.x было существенно ограничено.
Tatu Ylonen, автор ssh, организовал компанию "SSH Communications Security Oy" которая обеспечивает коммерческую поддержку и лицензирование ssh. Эта компания работает совместно с "Data Fellows", которая занимается продажей ssh лицензий. Более полную информацию можно найти на http://www.datafellows.com/ и http://www.ssh.fi/.
Официальная версия имеет PGP-подпись с ключом ID
DCB9AE01 1995/04/24 Ssh distribution key <ylo@cs.hut.fi> Key fingerprint = C8 90 C8 5A 08 F0 F5 FD 61 AF E6 FF CF D4 29 D9Ssh также доступен через анонимный доступ по ftp со следующих адресов:
gzip -c -d ssh-1.2.27.tar.gz | tar xvf -после чего перейдите в директорию ssh-1.2.27, прочитайте файл INSTALL, и следуя рекомендациям установите SSH.
Если вы установили клиентскую часть без setuid root, то это не помешает вам соединяться и входить на удаленные сервера, НО вы не сможете использовать форму .rhosts проверки подлинности входящего.
Вы можете запустить sshd из под своего account'а применив опцию -p для использования ssh на непривелигерованном порту (>1024), чтобы иметь возможность соединения с других машин по заданному порту ssh -p. Данный метод, как было замечено выше, позволяет производить соединения только под тем пользователем, под которым был запущен собственно sshd, и как правило демон не перестартует после перезагрузки машины.
Вы сами должны решать какой метод использовать в зависимости от ситуации.
Для пользователей очнь полезно будет введение на http://www.tac.nyc.ny.us/~kim/ssh/.
Автор этого опуса тоже имеет несколько статей об SSH опубликованных в Sunworld журнале.
Введение в SSH, достижения, и тд и тп:
Конфигурирование, установка, и тд и тп:
Если эти ресурсы не помогут, вы можете послать вопрос в группу новостей
Usenet comp.security.ssh или
отправить свой вопрос в список рассылки пользователей ssh ssh@clinet.fi
Для подписки отошлите письмо на majordomo@clinet.fi
c
subscribe ssh
в теле письма.
Перед подпиской вы можете поискать ответ на ваш вопрос в архиве на
ниже список ssh клиентов и серверов.
Существует список рассылки для версии OS/2. Для подписки отправьте письмо на majordomo@clinet.fi с
subscribe ssh-os2в теле сообщения.
Их можно собирать автоматически, каждую ночь, используя имеющийся в дистрибутиве скрипт написанный на Perl'е make-ssh-known-hosts.pl или с помощью быстрой утилиты ssh-keyscan, доступной с ftp://cag.lcs.mit.edu/pub/dm/ или ftp://ftp.cs.hut.fi/ssh/contrib/.
Thomas Konig написал скрипт разбирающий и анализирующий вывод вышеуказанных утилит, проверяя наличие новых ключей, сообщая о тех host'ах которые сменили свои ключи (дабы предотвратить атаки) и в завершение создавая новый файл ключей. Этот скрипт доступен с http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.
На основе этих утилит вы можете написать свои для постоянной проверки public
keys. Когда на новых машинах заработает ssh или произойдет изменение ключей на
уже работающих, возможно вы захотите высылать уведомления или связаться с хозяевами
этих машин напрямую чтобы предупредить возможные атаки хакеров.
http://www.net.lut.ac.uk/psst/
Существенное что из этого родилось это lsh, полностью соответствующий IETF (закрытый на сколько это возможно) sec-sh (SSHv2) клиент сервер.
Попробуйте найти lsh здесь: http://www.lysator.liu.se/~nisse/archive/
Следующая Глава, Предыдущая Глава
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы
На сегодняшний день быстродействие CPUs[процессоров] таково, что снижение производительности[на шифрации-дешифрации] если оно и есть? возможно заметить лишь на скоростях локального Ethernet или более быстрых сетей.
Тем не менее вы можете использовать метод шифрации "blowfish" вместо IDEA, который работает по умолчанию, для увеличения производительности, достаточно задать опцию -c blowfish.
Оцените приведенные ниже результаты измерений скорости передачи для разных методов шифрации между двумя компьютерами P5/90 и 486/100, оба под управлением OS Linux, файлы передавались с использованием "scp" по сильно загруженному Ethernet.
Была выбрана модель t=a+x/b; где a - _пусковое_ время, b - установленная скорость передачи. Также был использован коэффициент 68.3% confidence intervals для данных, как определено по алгоритму Levenberg-Marquardt примененному в версии pre-3.6 gnuplot.
Encryption a[s] da[s] b[kB/s] db[kB/s] none 2.37 0.37 386.1 5.8 rc4 1.96 0.27 318.2 2.9 tss 2.33 0.37 298.5 3.5 des 2.07 0.19 218.8 1.0 idea 2.25 0.45 169.6 1.3 3des 1.92 0.11 118.2 0.2При передаче через сильно нагруженный Ethernet, использование rc4 метода шифрации вместе со сжатем будет действительно значительно быстрее чем использование rcp.
Если вы используете rdist, то не забудьте при его компиляции задать ему путь к ssh. Дополнительно можно можно использовать опцию -P, чтобы rdist использовал ssh вместо rsh.
Если вы используете проверку пароля, в версиях rdist с 6.1.2 по 6.1.5, вам необходимо применить приведенный ниже patch[правка]:
--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996 +++ src/rshrcmd.c Tue Jun 11 16:52:05 1996 @@ -63,7 +63,7 @@ /* child. we use sp[1] to be stdin/stdout, and close sp[0]. */ (void) close(sp[0]); - if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) { + if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) { error("dup2 failed: %s.", SYSERR); _exit(255); } <p>Данную правку необходимо применить если при работе rdist вы получаете сообщение "Warning: Denied agent forwarding because the other end has too old version." данная ошибка возникает при соединение ssh-клиента 1.2.27 или более позднего со старыми версиями ssh-сервера.
Другой путь использовать в качестве замены rdist -> rsync, который специально был написан для работы с ssh и гораздо лучше адаптирован к пропускной ширине канала. Более подробно об rsync смотрите на ftp://samba.anu.edu.au/pub/rsync или ftp://sunsite.auc.dk/pub/unix/rsync.
Однако здесь имеются _подводные_ камни связанные с перенаправлением TCP соединений. Потому что ретрансляция может произойти в одно и тоже время как TCP соединения через ssh так и TCP перенаправления через PPP/ssh туннель. Так что в данном случае лучше использовать криптованный IP-туннелинг по UDP, а о возможностях можно прочитать в проекте CIPE: http://www.inka.de/~bigred/devel/cipe.html .
В принципе, можно сделать реализацию для NFS, но пока еще не сделано.
Сетевые сервисы, которые полностью реализованы на UDP, такие как DNS, пока еще не реализованы в ssh, однако это принципиально возможно.
OpenGL, запускаемый как расширение X-сервера не должен создавать проблем. Вам лишь необходимо установить переменную среды GLFORCEDIRECT=no.
Допустим вы находитесь на компьютере называемом "myhost" и хотите произвести ftp соединение с компьютером под именем "ftphost". Тогда на компьютере myhost" необходимо воспользоваться перенаправлением TCP через ssh:
myhost$ ssh -L 1234:ftphost.example.com:21 ssh-serverВыполнив эту команду вы войде на компьютер "ftphost", а порт "myhost":1234 будет перенапрвлен с использованием ширования на "ftphost":21. [от себя добавлю что теперь это окно у вас как бы в холостом режиме, но вы можете в нем поработать... ;-)]
Теперь в другом окне на компьютере "myhost", можете запускать клиента ftp следующим образом:
myhost$ ftp localhost 1234 220 ftphost FTP server (Foonix 08/15) ready. Name: (myhost:yourname): 331 Password required for yourname Password: 230 User yourname logged in.Это работает в том случае если удаленный ftp daemon[сервер] позволяет выполнять PORT команды с указанием адреса host'а отличным от того с которого поступают команды[типа proxy] и если ftp-client тоже использует PORT. Это работает для "vanilla" Unix ftp клиентов и серверов, но может не работать для продвинутых FTPD-серверов, таких как wu-ftpd.
к переводу:
от себя замечу, очень давно, те старые wu-ftpd у меня без проблем работали в пассивном
режиме, а вся проблема упиралась в клиентскую часть, замечено на Convex-OS/SPP-UX[якобы HP]/HP-UX/OSF1.
Решение простое, "man ftp" и если вы нашли там возможность использования пассивного режима PASV, например команда proxy, возможно вам повезло, еще проще - да
поставьте вы какой-либо из продвинутых ftp-клиентов их сейчас масса.
Для определения с какой стороны обрезается, не поддерживается пассивный режим возьмите заведомо работающие клиент или сервер и посмотрите диагностику.
Для POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) написал скрипт который защищает передачу пароля и данных используя ssh. Он не требует изменений существующих POP клент-сервера и доступен с ftp://ftp.internatif.org/ pub/unix/gwpop/ .
Другие сетевые сервисы можно также обезопасить подобным образом. Однако стоит отметить что передача нешифрованных _данных_ ftp остается подверженной похищению и подмене.
или другое место:
http://www.ncsa.uiuc.edu/General/CC/ssh/ssh_ncsa_mods.html
Следующая Глава, Предыдущая Глава
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы
Если вы хотите опубликовать bug report[сообщение об ошибке], отправьте письмо по адресу ssh-bugs@clinet.fi содержащее следующее:
Если вы обнаружили подобные проблемы в Solaris 2.5.1, просто установите более свежую версию ssh - 1.2.14 или еще свежее, это должно решить ваши проблемы.
Получите и установите патч 103187-02 (for x86, 103188-02) для решения этой проблемы. Данная проблема возможна решена в Solaris 2.5.1.
Отключите всю оптимизацию для ssh-keygen, или используйте gcc. Заметьте что Gcc 2.7.2 имеет проблемы на Alpha и тем не менее.
RhostsRSAAuthentication функционально заменяет 'r' утилиты; это требует чтобы программа ssh имела "setuid root", "secret key" в /etc/host_key файле, соответствующий "public key" в /etc/ssh_known_hosts и запись в ~/.[sr]hosts или /etc/[s]hosts.equiv.
RSAAuthentication выполняется на уровне пользователя и требует наличия ~/.ssh/identity со стороны клиента(сгенерированного ssh-keygen) и файла ~/.ssh/authorized_keys со стороны сервера.
Ssh пытается вернуться к методу "r" команд когда не может соединиться с sshd демоном удаленной машины и в результате пытается запустить старый rsh для использования старого протокола.
Существуют всего два предположения почему это происходит:
В этом случае вы можете перенести старые бинарники rsh и rlogin в /usr/old, отпатчить их с запустив Perl скрипт
perl -pi.orig -e 's+/usr/(bin|ucb)/rlogin+/usr/old/rlogin+g ;' /usr/old/rshкоторый поправит двоичные модули и положит их в /usr/old/rsh.orig.
И теперь осталось переконфигурировать ssh с --with-rsh=/usr/old/rsh. Для плохо понимающих, в последнем варианте учитывается что путь в бинарнике имеет конкретную длинну, те чревато заменять например /usr/bin/rlogin на /usr/local/old/rlogin.
Это также могло произойти при сборке ssh с --with-libwrap и необходимая sshdfwd-X11: строка отсутствует в файле /etc/hosts.allow те в файле не указан host с которого разрешено заходить.
Некоторые изменения были сделаны в протоколе версии 1.2.14 чтобы избежать этого, но проблема межде версией 1.2.14 и более ранними осталась. Установите более свежие версии ssh, желательно последние и с обоих сторон.
make distclean configure --disable-asmдля компиляции.
Попробуйте применить следующие правки к 1.2.16 or 1.2.17 for a fix. Это исправлено в 1.2.18 и позже.
--- serverloop.c.orig Tue Jan 21 14:38:25 1997 +++ serverloop.c. Tue Jan 21 14:37:54 1997 @@ -405,7 +405,7 @@ buffer_len(&stdin_buffer)); if (len <= 0) { - if (errno != EWOULDBLOCK) + if ((errno != EWOULDBLOCK) && (errno != EAGAIN)) { if (fdin == fdout) shutdown(fdin, 1); /* We will no longer send. */
Среди других потенциальных проблем, такая как перенаправление соединений через -Lx:host:port будет выполнять соединение "host:port" от "root uid", с того моммента как first дочерний процесс стартует. А это означает что когда заданный компьютер попытается идентифицировать от какого пользователя идет запрос, он получит что от "root", вместо реального пользовательского uid.
Это ситуация продолжает оставаться известной как "ошибка", и неизвестно
будет ли данная технологическая проблема исправлена в следующих реализациях.
http://www.ncsa.uiuc.edu/General/CC/ssh/patch_repository/
Его комментарии:
"Я выложил правки сделанные нами, плюс которые были _постированы_ в конференции и несколько мне неизвестных. Имеется страница с описание этих правок, но если у кого то имееются дополнительные сведения дайте мне знать. Большинство правок относится к версии 1.2.x, но я с успехом использовал многие для 2.0.x."
Следующая Глава, Предыдущая Глава
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы
Как и в отношении любого свободно распространяемого продукта, сложно сделать прогноз предполагаемого количества использующих ssh. Уместнее будет оценка того что более 1000 институтов в 40 странах используют ssh, а данная оценка основана на
Ssh проложил курс в стандарты интернет и это подразумевает что нужны новые, вторичные, независимые разработки его применения.
Вы должны осозновать что методы шифрации RSA,IDEA запатентованы и необходимо получить соответствующие разрешения для написания второй реализации.
Спасибо Thomas.Koenig написавшему оригинальный FAQ еще по версии SSH1.
Спасибо "списку-рассылки" ssh за предоставленные вопросы и ответы отраженные
в данном документе.
Предыдущая Глава,
Содержание этой главы, Общее Содержание
В начало документа, В начало этой главы