[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Безопасность" (Архив | Для печати)

Вступление.

Данное руководство было написано на основе использования ssh версии 1.2.x протокола SSH1.5. Но оно вполне может быть использовано и при работе с ssh версии 2.x, что соответствует протоколу SSH2.
 Руководство было написано очень давно но имелся лишь текстовый вариант. Взявшись за проект UnixGems - Сокровища Unix, а попросту рускоязычная документация Unix, я постараюсь время от времени вносить поправки и дополнять это руководство.

Примечание: Если найдется хотя бы один пользователь, у которого возникнут проблемы с использованием ssh версии 2.x, я напишу новое или расширю это руководство. Хотя в SSH2.x очень хорошее и толковое описание и он более удобен и прозрачен для пользователей.

1. Коротко о работе SSH.
2. О шифровании методом публичных ключей.
3. Создание вашего ключа аутентикации и изменение парольной фразы
4. Авторизация доступа, директории и права.
5. Вход на удаленную систему.
6. Хранение ключей авторизации в памяти.
• запуск системы X11 на локальном дисплее.
• запуск системы X11 через сессию xdm.
7. Управление ключами авторизации в памяти.
8. Запуск команд на удаленной системе.
9. Копирование файлов между системами.
10. Изменение стандартных настроек.
11. Автостарт ssh-agent с CDE.
12. SSH и туннелинг.
13. Возможные проблемы.
14. Клиенты SSH для Windows.
15. Ссылки на другие полезные источники информации.

SSH и используемые методы проверки достоверности:

• проверка достоверности на уровне самих машин, хостов - hosts
• проверка достоверности на уровне пользователя включая:
  • /etc/hosts.equiv и .rhosts/.shosts -  если собрано с поддержкой-откатом на rsh/rlogin.
  • XAUTHORITY - если правильно собран SSH, а X-Window за пущен с авторизацией или через XDM.
  • RSA - аутентикацию, если SSH собран с поддержкой RSA.
  • Проверку достоверности посредством "public key".
  • Шифрация данных любым из доступных методов используемых в SSH,  по-умолчанию - IDEA.
  • Использование парольной фразы - passphrase.
• совместная работа SSH с другими методами проверки безопасности,  TIS, Kerberos, SSL, C2 и так далее, подробнее см. документацию SSH.

Понятно что SSH работает используя технологию Клиент<->Сервер, удивительно что пользователи зачастую непонимают то что они делают. :(

В случае использования SSH, данную технологию необходимо понимать так:

         Client (workplace)  <---------------->  Server (remote machine)

          ssh/slogin/scp     <---------------->    sshd

Если пользователь в качестве workplace - рабочего места может использовать разные машины - Client, соответственно, на каждой из них необходимо запустить ssh-keygen. В качестве рабочего места могут быть дополнительно подключенные терминалы, консоль и тд и тп.

Тогда схематически можем изобразить следующее:

         Client (workplace)  <---------------->  Server (remote machine)

          ssh/slogin/scp     <---------------->    sshd

  $HOME/.ssh/                         |          $HOME/[.ssh/]
            /[authorized_keys]        |               /.Xauthority
            /identity                 |               /.rhosts[.shosts]
            /identity.pub             |                     /[authorized_keys]
            /known_hosts              |                     /[identity]
            /random_seed              |                     /[identity.pub]
                                      |                     /[known_hosts]
                                      |                     /[random_seed]

Из данной схемы ВСЕ ОЧЕВИДНО, [] - кавычки как и всегда, обозначают необязательное, но возможное присутствие, в зависимости от технологического варианта, те например, Server может быть в свою очередь Client, в том случае, если пользователь имеет возможность локального [в отличие от удаленного] доступа к нему.

О шифровании методом публичных ключей.

Шифрование методом публичного ключа использует "public key" для шифрации и "private key" для дешифрации данных. Сам термин "public key" указывает на тот факт, что использовать этот метод можно без страха за безопасность пере-даваемых данных или ключ дешифрации, ибо последний просто не передаетсяпо данной технологии.

Это означает, что нет опасности передачи вашего "public key" или содержимого файла $HOME/.ssh/identity.pub по электронной почте или другими методами системному администратору удаленного сервера чтобы ое помечтил эти данные в файл $HOME/.ssh/authorized_keys на удаленном сервере.

Если кто-либо хочет получить несанкционированный доступ к вашим данным или воспользоваться вашим входом при авторизации, то ему необходимо сначала получить доступ к вашему личному ключу $HOME/.ssh/identity и соответственно дешифровать его для идентификации сперва самого себя.

Однако для большей защиты вашего "private key", при его генерации с помощью программы keygen необходимо задать passphrase - парольную-фразу для шифрации содержимого файла, когда он будет записываться на файловую систему. Это должно предотвратить от дешифрации личного ключа даже если кто-либо имеетдоступ в вашу домашнюю директорию и файлам.

Создание вашего ключа аутентикации и изменение парольной фразы.

Итак, первое что вам необходимо сделать - это использовать команду ssh-keygen для создания собственных ключей авторизации. Достаточно просто запустить эту команду, ключи использованные в этой команде по-умолчанию обычно удовлетворяют все потребности.

Совет, перед запуском ssh-keygen сначала придумайте и запомните фразу-пароль[passphrase], которая должна удовлетворять следующим рекомендациям:

• содержать последовательность отдельных слов
• удобнее и лучше, если слова будут разделяться пробелами; это не только допускается, но и приветствуется в целях увеличения секретности
• изменить некоторые слова на предмет неверного произношения(соответственно и их написание должно быть изменено)
• заменить некоторые буквы в словах на цифры или добавить набор цифр в вашу секретную пароль-фразу. Чем большему количеству перечисленных выше рекомендаций будет соответствовать ваша пароль-фраза, тем надежнее будет она сама и ваш личный ключ - "private key".

/* не забудьте что вводимая passphrase не высвечивается */

unix1% ssh-keygen
 Initializing random number generator...
 Generating p:  .............................................++ (distance 830)
 Generating q:  .......................................++ (distance 636)>
 Computing the keys...
 Testing the keys...
 Key generation complete.
 Enter file in which to save the key ($HOME/.ssh/identity):
 Enter passphrase: pust' vsegda 2000
 Enter the same passphrase again: pust' vsegda 2000
 Your identification has been saved in /home/lavr/.ssh/identity.
 Your public key is:
 1024 37 [lots of numbers] lavr@unix1
 Your public key has been saved in /home/lavr/.ssh/identity.pub
unix1%

• для оффиса
• для личной системы
• для Internet service provider (ISP) системы
• для унивеситета
• для научно-исследовательского центра или интститута

Помните что при необходимости, вы всегда можете изменить свою пароль-фразу выполнив команду ssh-keygen с опцией -p , например:

/* не забудьте что вводимая passphrase не высвечивается */

unix1% ssh-keygen -p
 Enter file in which the key is ($HOME/.ssh/identity): 
 Enter old passphrase: pust' vsegda 2000
 Key has comment 'lavr@sunhe'
 Enter new passphrase: budet new 3000
 Enter the same passphrase again: budet new 3000
 Your identification has been saved with the new passphrase.
unix1%

Для того чтобы расширить или ограничить список систем с которых разрешен разрешен доступ необходимо создать файл $HOME/.ssh/authorized_keys в который поместить список "public key" тех систем которым разрешен доступ.

Обычно пользователи хотят иметь авторизованный доступ на _локальную_ систему использую локальный ключ(этод метод хорош там где используется метод разделяемых домашних директорий с использованием NFS) В данном случае достаточно просто скопировать файл $HOME/.ssh/identity.pub с "public key" в файл $HOME/.ssh/authorized_keys.

unix1% cd ~/.ssh
unix1% cp identity.pub authorized_keys

Всегда следите за правами доступа к любым вашим файлам, но особенно к тем, с которыми связана безопасность вашей работы и сохранность данных.

Если после всех проделанных мероприятий, удаленная система отказывает вам в доступе, попробуйте проверить права и доступ к директориям и файлам связанным с SSH:

∙ ~/.ssh
∙ ~/.ssh/authorized_keys

unix1% cd
unix1% ls -ld . .ssh .ssh/authorized_keys
 drwxr-xr-x  36 lavr  dug  4096 Jul 25 02:24 .
 drwxr-xr-x   2 lavr  dug   512 Apr 10 02:30 .ssh
 -rw-r--r--   1 lavr  dug  1674 Apr 10 02:29 .ssh/authorized_keys
unix1%

unix1% cd
unix1% chmod go-w . .ssh .ssh/authorized_keys
unix1%

Примечание:

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

Строго говоря, личный ключ - файл identity, должен жестко иметь права 0600, остальное на ваше усмотрение и исходя из вашего понимания и отношения к безопасности, да, ну и конечно файл с "public key" - identity.pub==0644.

Я бы советовал иметь права на директорию $HOME/.ssh==0700 , а на содержимое подобно[можете заметить что у меня .ssh==755]:

unix1:/home/lavr> ls -la .ssh
total 42
 drwxr-xr-x   2 lavr  dug    512 26 дек 06:50 .
 drwxr-xr-x  61 lavr  dug   5632  6 апр 22:45 ..
 -rw-------   1 lavr  dug    672 26 дек 06:39 authorized_keys
 -rw-------   1 lavr  dug    539 26 дек 06:39 identity
 -rw-r--r--   1 lavr  dug    343 26 дек 06:39 identity.pub
 -rw-------   1 lavr  dug  31654 29 мар 11:49 known_hosts
 -rw-------   1 lavr  dug    512  6 апр 22:45 random_seed
unix1:/home/lavr>

Чтобы небыло путаницы с разрешенным доступом через файл $HOME/.ssh/authorized_keys приведем пример с использованием схематики, где машина unix1 - Client, а удаленные машины unix2 [второе имя - mammoth] и cv - Servers:

         Client (workplace)  <---------------->  Server (remote machine) 
          ssh/slogin/scp     <---------------->    sshd

 unix1:~lavr/.ssh/                     unix2:~lavr/.ssh/
                 /[authorized_keys]  |                  пустота 
                 /identity           |                  
                 /identity.pub       |                 
                 /known_hosts        |                 
                 /random_seed        |                 
                                     |                 
                                     |                

Первое что мы можем сделать - проверить, использует ли удаленная машина поддержку SSH, то есть работает ли на ней сервер - sshd. Для этого нам достаточно воспользоваться командой telnet с указанием порта - 22, именно этот порт используется SSH по-умолчанию:

unix1:/home/lavr> telnet unix2 22
Trying 159.93.17.122...
Connected to unix2.jinr.dubna.su.
Escape character is '^]'.
SSH-1.5-1.2.27

unix1:/home/lavr> telnet sungraph 22
Trying 159.93.20.105...
telnet: Unable to connect to remote host: Connection refused
unix1:/home/lavr> telnet sungraph 
Trying 159.93.20.105...
Connected to sungraph.jinr.dubna.su.
Escape character is '^]'.


SunOS UNIX (sungraph)

login: Connection closed by foreign host.
unix1:/home/lavr> 

Видим что на удаленной машине sungraph отсутствует демон sshd а это значит что мы не можем безопасно воспользоваться SSH.

Важно отметить что если SSH компилировался с поддержкой rsh/rlogin то в случае попытки входа на удаленную машину без SSH, slogin будет переходить на авторизацию через /etc/hosts.equiv и .rhosts, впрочем, если данные файлы содержат о вас достоверную на удаленной машине с sshd - демоном, то попытка использовать данную авторизацию, также будет использована.

Имея или не имея на удаленной машине unix2 директорию .ssh я в любом случае могу воспользоваться SSH для безопасного входа и удаленной работы на unix2, пример, состояние на удаленной машине unix2:

mammoth:/usr/home/lavr> ls -la .ssh
ls: .ssh: No such file or directory
mammoth:/usr/home/lavr> 

попытаемся зайти с unix1 на unix2:

unix1:/home/lavr> slogin -v unix2
SSH Version 1.2.26 [i386-unknown-freebsd2.2.8], protocol version 1.5.
Compiled with RSAREF.
unix1.jinr.dubna.su: Reading configuration data /usr/local/etc/ssh_config
unix1.jinr.dubna.su: ssh_connect: getuid 310 geteuid 0 anon 0
unix1.jinr.dubna.su: Connecting to unix2 [159.93.17.122] port 22.
unix1.jinr.dubna.su: Allocated local port 787.
unix1.jinr.dubna.su: Connection established.
unix1.jinr.dubna.su: Remote protocol version 1.5, remote software version 1.2.27
unix1.jinr.dubna.su: Waiting for server public key.
unix1.jinr.dubna.su: Received server public key (768 bits) and host key (1024 bits).
unix1.jinr.dubna.su: Host 'unix2' is known and matches the host key.
unix1.jinr.dubna.su: Initializing random; seed file /home/lavr/.ssh/random_seed
unix1.jinr.dubna.su: Encryption type: idea
unix1.jinr.dubna.su: Sent encrypted session key.
unix1.jinr.dubna.su: Installing crc compensation attack detector.
unix1.jinr.dubna.su: Received encrypted confirmation.
unix1.jinr.dubna.su: Trying rhosts or /etc/hosts.equiv with RSA host authentication.
unix1.jinr.dubna.su: Remote: Rhosts/hosts.equiv authentication refused: client user 'lavr', server user 'lavr', client host 'unix1.jinr.dubna.su'.
unix1.jinr.dubna.su: Server refused our rhosts authentication or host key.
unix1.jinr.dubna.su: Connection to authentication agent opened.
unix1.jinr.dubna.su: Trying RSA authentication via agent with 'lavr@unix1.jinr.dubna.su'
unix1.jinr.dubna.su: Server refused our key.
unix1.jinr.dubna.su: RSA authentication using agent refused.
unix1.jinr.dubna.su: Trying RSA authentication with key 'lavr@unix1.jinr.dubna.su'
unix1.jinr.dubna.su: Server refused our key.
unix1.jinr.dubna.su: Doing password authentication.
lavr@unix2's password: 
^^^^^^^^^^^^^^^^^^^^^^--- вводим пароль и заходим на unix2.

unix1.jinr.dubna.su: Requesting pty.
unix1.jinr.dubna.su: Failed to get local xauth data.
unix1.jinr.dubna.su: Requesting X11 forwarding with authentication spoofing.
unix1.jinr.dubna.su: Requesting authentication agent forwarding.
unix1.jinr.dubna.su: Requesting shell.
unix1.jinr.dubna.su: Entering interactive session.
Last login: Fri Apr  7 15:33:57 2000 from unix1.jinr.dubna
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

FreeBSD 2.2.8-STABLE (MMTH) #0: Sun Jan  9 22:37:00 MSK 2000

Welcome to FreeBSD!

Handbook is in /usr/share/doc/handbook and the FAQ in /usr/share/doc/FAQ.
lynx /usr/share/doc/handbook & lynx /usr/share/doc/FAQ.

No new messages.
mammoth:/usr/home/lavr>

Можем смело работать ощущая себя в безопасности. Следует отметить что введенный пароль НЕ МОГ БЫТЬ ПОДСЛУШЕН в сети потому что технологически SSH сначала начинаеть шифрацию данных и лишь затем устанавливает соединение с удаленной машиной, те вводимый нами пароль идет шифрованным. А соединение происходило по 22-ому порту.

Теперь изменим авторизацию используя "public key" пользователя lavr с клиентской машины unix2 - unix1:~lavr/.ssh/identity.pub для беспарольного захода на машину unix2.

Для этого необходимо на удаленной машине unix2 создать файл ~lavr/.ssh/authorized_keys и поместить в него "публичный ключ" клиента что находится в файле unix1:~lavr/.ssh/identity.pub.

Рассмотрим схематично, авторизация методом authorized_keys:

Пример содержимого файла unix1:~lavr/.ssh/identity.pub

---------------------------- identity.pub ------------------------------------
1024 33 123455613571294786678234678124109412884011689992618043976213690319207626
04778809267037467162812346789078213478908712346796123474787443160033234663145614
49429937525705396999378436889184517007432662261198826716033688101069276271769654
25643258747621735477817990558818651836009050064859034674736459969312463503021 la
vr@unix1.jinr.dubna.su
---------------------------- end of identity.pub -----------------------------

Указанный выше публичный ключ - это одна строка которую необходимо скопировать
в файл authorized_keys на машине unix2, любыми доступными вам способами:

      unix1:~lavr/.ssh/identity.pub -> unix2:~lavr/.ssh/authorized_keys

unix2:/home/lavr/.ssh> chmod 0600 authorized_keys
unix2:/usr/home/lavr/.ssh> ls -la authorized_keys 
-rw-------  1 lavr  dug  343  7 апр 15:18 authorized_keys
unix2:/usr/home/lavr/.ssh> 


         Client (workplace)  <---------------->  Server (remote machine)
          ssh/slogin/scp     <---------------->    sshd

 unix1:~lavr/.ssh/                     unix2:~lavr/.ssh/
                 /[authorized_keys]  |                 /authorized_keys с
                 /identity           | публичным ключом lavr@unix1
                 /identity.pub       |
                 /known_hosts        |
                 /random_seed        |
                                     |
                                     |

Посмотрим действия SSH при использовании authorized_keys:

unix1:/home/lavr> slogin -v unix2
SSH Version 1.2.26 [i386-unknown-freebsd2.2.8], protocol version 1.5.
Compiled with RSAREF.
unix1.jinr.dubna.su: Reading configuration data /usr/local/etc/ssh_config
unix1.jinr.dubna.su: ssh_connect: getuid 310 geteuid 0 anon 0
unix1.jinr.dubna.su: Connecting to unix2 [159.93.17.122] port 22.
unix1.jinr.dubna.su: Allocated local port 786.
unix1.jinr.dubna.su: Connection established.
unix1.jinr.dubna.su: Remote protocol version 1.5, remote software version 1.2.27
unix1.jinr.dubna.su: Waiting for server public key.
unix1.jinr.dubna.su: Received server public key (768 bits) and host key (1024 bits).
unix1.jinr.dubna.su: Host 'unix2' is known and matches the host key.
unix1.jinr.dubna.su: Initializing random; seed file /home/lavr/.ssh/random_seed
unix1.jinr.dubna.su: Encryption type: idea
unix1.jinr.dubna.su: Sent encrypted session key.
unix1.jinr.dubna.su: Installing crc compensation attack detector.
unix1.jinr.dubna.su: Received encrypted confirmation.
unix1.jinr.dubna.su: Trying rhosts or /etc/hosts.equiv with RSA host authentication.
unix1.jinr.dubna.su: Remote: Rhosts/hosts.equiv authentication refused: client user 'lavr', server user 'lavr', client host 'unix1.jinr.dubna.su'.
unix1.jinr.dubna.su: Server refused our rhosts authentication or host key.
unix1.jinr.dubna.su: Connection to authentication agent opened.
unix1.jinr.dubna.su: Trying RSA authentication via agent with 'lavr@unix1.jinr.dubna.su'
unix1.jinr.dubna.su: Received RSA challenge from server.
unix1.jinr.dubna.su: Sending response to RSA challenge.
unix1.jinr.dubna.su: Remote: RSA authentication accepted.
unix1.jinr.dubna.su: RSA authentication accepted by server.
unix1.jinr.dubna.su: Requesting pty.
unix1.jinr.dubna.su: Failed to get local xauth data.
unix1.jinr.dubna.su: Requesting X11 forwarding with authentication spoofing.
unix1.jinr.dubna.su: Requesting authentication agent forwarding.
unix1.jinr.dubna.su: Requesting shell.
unix1.jinr.dubna.su: Entering interactive session.
Last login: Fri Apr  7 15:37:05 2000 from unix1.jinr.dubna
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

FreeBSD 2.2.8-STABLE (MMTH) #0: Sun Jan  9 22:37:00 MSK 2000

Welcome to FreeBSD!

Handbook is in /usr/share/doc/handbook and the FAQ in /usr/share/doc/FAQ.
lynx /usr/share/doc/handbook & lynx /usr/share/doc/FAQ.

No new messages.
mammoth:/usr/home/lavr> 

Что и требовалось доказать - пароль вводить не требуется поскольку мы разрешаем входить пользователю lavr@unix1. Сие может быть актуально для группы пользователей которым вы доверяете, просто заносите их публичные ключи в файл authorized_keys той машины, куда вы разрешаете входить тем, кому абсолютно доверяте. В качестве примера продолжим рассмотрение lavr@unix1 и unixgems@cv, но уже без опции -v, то есть без проверки:

unix1:/home/lavr> slogin cv -l unixgems
No mail.
No new messages.
[cv]~ > ls -la .ssh
total 6
drwxr-xr-x  2 unixgems      512 Mar 17 15:42 .
drwxr-xr-x 10 unixgems     1024 Apr  7 17:00 ..
-rw-------  1 unixgems     1004 Mar 17 15:45 authorized_keys
-rw-------  1 unixgems      512 Mar 26 16:36 random_seed
[cv]~ > 

Посмотрим содержимое файла cv:~unixgems/.ssh/authorized_keys:

[cv]~/.ssh > cat authorized_keys 
1024 33 678678123496923479123479165242109412884011689992618043976213690319207626
04778809267037467162833562928533292936139256720809420334787443160033234663145614
49429937525705396999378436889184517007432662261198826716033688101069276271769654
25643258747621735477817990558818651836009050064859034674736459969312463503021 
lavr@unix1.jinr.dubna.su
1024 37 137290359433182513579617890789123467129671297912312761273466645672942194
55970778052199218487445994523144629525988441011878648710134855446588870011860160
77772308703155696414837775201650380942285951978078879612311758535089405534081292
94415364237239835774809190340205754563617283970410932262411362690843796366679 
grom@ultra.jinr.dubna.su
1024 37 130519989598501766767291364712467912674967231401723846127349672134678318
22302017753994633382264332578230406493484282790872111790029413922641217785693235
71826624741446328242429959045190528987359008994056451409547886075549563303970423
73079581597300609261185396227802478893345430979943132249249559815951890929333 
serg@sunhe.jinr.ru
[cv]~/.ssh > id
uid=8333(unixgems) gid=100(dug) groups=100(dug)
[cv]~/.ssh > 

По содержимому файла authorized_keys мы видим что пользователь unixgems@cv разрешает заходить под своим account своим единомышленникам:

• lavr@unix1.jinr.dubna.su
• grom@ultra.jinr.dubna.su
• serg@sunhe.jinr.ru

Не забудьте - публичный ключ представляет из себя ОДНУ ЦЕЛУЮ СТРОКУ.

Вход на удаленную систему.

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

unix1% slogin spp
 Enter passphrase for RSA key 'lavr@spp.jinr.dubna.su': pust' vsegda 2000
 Last login: Wed Oct 16 20:37:00 1996 from idefix
 [more output from the remote machine]
spp%

Примечание: Иногда запрос на аутентикацию посредством passphrase имеет иную причину и связан с различными ньюансами связанными с достоверностью вхождения с разных машин, но с одной $HOME директорией объединенной через NFS, либо с уже имеющейся открытой сессией SSH, либо с проблемами авторизации X-Window.

Если ваше регистрационное имя на обоих системах, локальной и удаленной, различаются, вы можете использовать опцию "-l username" для указания имени на удаленной системе. Как например:

unix1% slogin -l lavr nusun 
 Last login: Sun Oct 13 14:55:17 1997 from nusun.jinr.ru
 [more output from the remote machine]
nusun%

Если у вас возникли какие-либо проблемы при входе на удаленную систему используйте опцию -v для просмотра отладочной информации и все ваши проблемы исчезнут после того как вы установите в чем ошибка.

Например:

unix1% slogin -v cv
SSH Version 1.2.22 [i386-unknown-freebsd2.2.5], protocol version 1.5.
Standard version.  Does not use RSAREF.
unix1.jinr.dubna.su: Reading configuration data /usr/local/etc/ssh_config
unix1.jinr.dubna.su: ssh_connect: getuid 310 geteuid 0 anon 0
unix1.jinr.dubna.su: Connecting to cv [159.93.17.13] port 22.
unix1.jinr.dubna.su: Allocated local port 777.
unix1.jinr.dubna.su: Connection established.
unix1.jinr.dubna.su: Remote protocol version 1.5, remote software version 1.2.22
unix1.jinr.dubna.su: Waiting for server public key.
unix1.jinr.dubna.su: Received server public key (768 bits) and host key (1024 bi
ts).
unix1.jinr.dubna.su: Host 'cv' is known and matches the host key.
unix1.jinr.dubna.su: Initializing random; seed file /home/lavr/.ssh/random_seed
unix1.jinr.dubna.su: Encryption type: idea
unix1.jinr.dubna.su: Sent encrypted session key.
unix1.jinr.dubna.su: Received encrypted confirmation.
unix1.jinr.dubna.su: Trying rhosts or /etc/hosts.equiv with RSA host authenticat
ion.
unix1.jinr.dubna.su: Remote: Accepted by .shosts.
unix1.jinr.dubna.su: Received RSA challenge for host key from server.
unix1.jinr.dubna.su: Sending response to host key RSA challenge.
unix1.jinr.dubna.su: Remote: Rhosts with RSA host authentication accepted.
unix1.jinr.dubna.su: Rhosts or /etc/hosts.equiv with RSA host authentication acc
epted by server.
unix1.jinr.dubna.su: Requesting pty.
unix1.jinr.dubna.su: Failed to get local xauth data.
unix1.jinr.dubna.su: Requesting X11 forwarding with authentication spoofing.
unix1.jinr.dubna.su: Requesting authentication agent forwarding.
unix1.jinr.dubna.su: Requesting shell.
unix1.jinr.dubna.su: Entering interactive session.
Last login: Tue Jun 30 08:21:28 1998 from cv.jinr.dubna.su

        Welcome to ConvexOS

    CONVEX computer Corporation

 /cern (CERN Soft) dirs tree
         and
 /local dirs tree
 mounted from BCV due to h/w problem.

 Samba services disabled temporary(?).

        Sorry.

No mail.
Message 107:
From: popovla
Date: Fri Jun 19 11:41:38 1998
Subject: LCTA 2-d floor servers
(8 lines) Display this message? (y)es, (n)o, (q)uit, (h)elp [y]: n
--Flushed--
cv:/home/b17c/lavr> 

Поскольку slogin есть ничто иное как линк на ssh, один из вариантов входа на удаленную машину, можно изобразить так:

unix1:/home/lavr> ssh -l lavr unix2
Last login: Fri Apr  7 17:17:55 2000 from unix1.jinr.dubna
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.   All rights reserved.

FreeBSD 2.2.8-STABLE (MMTH) #0: Sun Jan  9 22:37:00 MSK 2000

Welcome to FreeBSD!

Handbook is in /usr/share/doc/handbook and the FAQ in /usr/share/doc/FAQ.
lynx /usr/share/doc/handbook & lynx /usr/share/doc/FAQ.

No new messages.
mammoth:/usr/home/lavr>

Хранение ключей авторизации в памяти.

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

Для запуска ssh-agent в качестве параметра необходимо указать имя команды которая будет им запущена, обычно это либо ваш shellлибо команда запуска оконной среды. Соответствено по выходу из такой команды все ключи будут удалены из памяти.

unix1% ssh-agent $SHELL
unix1%

Рассмотрим запуск оконной среды X11 на локальный дисплей.

Если у вас имеется локальная машина с установленной и настроенной средой X-Window system, вы можете получить полноценную оконную среду но с ключами в памяти при запуске через ssh-agent. Обычно X-Window system запускается отработкой скрипта startx с инициализацией клиентов из домашнего - .xinitrc или при его отсутствии системного файла xinitrc.

Например это можно выполнить так:

unix1% ssh-agent startx &

Системным администраторам могу описать свой путь решения запуска X-Window или вовсе запретить
X11 forwarding:

1. запуск X11 только через ssh-agent
2. обычный запуск и с использованием ssh-agent

unix1% ls -la /usr/local[/etc]/.[a-z]*
 -rw-r--r--  1 root  wheel     6 Jun  6  1997 /usr/local/etc/.bash_logout
 -rw-r--r--  1 root  wheel  2361 Dec 29  1997 /usr/local/etc/.bash_profile
 -rw-r--r--  1 root  wheel  1543 Dec 29  1997 /usr/local/etc/.bashrc
 -rwxr-xr-x  1 root  wheel  1267 May 18 13:46 /usr/local/etc/.cshrc
 -rwxr-xr-x  1 root  wheel  1534 Jan 23 14:59 /usr/local/etc/.login
unix1%

Примеры:

пользовательские файлы настройки среды:

unix1% cat .cshrc
source /usr/local/etc/.cshrc
unix1% cat .login
source /usr/local/etc/.login
unix1% cat .bashrc
. /usr/local/etc/.bashrc
unix1% cat .bash_profile
. /usr/local/etc/.bash_profile
unix1%

unix1% grep startx /usr/local/etc/.[a-z]*
/usr/local/etc/.bashrc:alias startx='ssh-agent startx'
/usr/local/etc/.cshrc:alias startx  'ssh-agent startx'
unix1%

unix1% grep ssh /usr/X11/lib/X11/xinit/xinitrc
#-ssh-auth
 until ssh-askpass | ssh-add -p; do true; done
unix1%

----------------------- cut from xinitrc -----------------------------------
...
until ssh-askpass | ssh-add -p; do true; done

xterm -geometry 80x40+8+9 -name login -ls -sb &
xconsole -geometry 480x130+0-0 -daemon -notify -verbose -fn fixed &
exec fvwm
----------------------- end of cut from xinitrc ----------------------------

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

Второй способ технически мало отличается от первого ибо приемы могут быть взаимодополнены или заменены, я подразумевал саму идею, в первом случае принудительный запуск X-Window через ssh-agent, а в данном способе использовать некий переходной этап - разрешить использование как обычного запуска, так и с использованием ssh-agent.

Просто переименовываем известный скрипт startx допустим в startX

unix1% mv startx startX

#!/bin/sh
if [ -d $HOME/.ssh ]
 then ssh-agent startX
 else startX
fi

------------------ cut from xinitrc ---------------------------------------
if [ -d $HOME/.ssh ]
 then until ssh-askpass | ssh-add -p; do true; done
fi
------------------ cut here -----------------------------------------------

unix1% cd
unix1% cp /usr/X11[R...]/lib/X11/xinit/xinitrc .xinitrc

Будьте аккуратны, все вышеизложенное касается запуска X-Window на локальной машине! [R...] - означает что путь зависит от того как и какая версия X-Window установлена.

Рассмотрим запуск X-Window через сессию xdm.

Если на вашем сервере или рабочей станции X-Window запускается через сеанс XDM, вам необходимо создание неких условий благодаря которым клиенты будут запущены под ssh-agent. Простейший способ, практически схожий с предыдущим - startx. Произвести инициализацию клиентов через .xinitrc, который в свою очередь будет вызываться из стартового файла .xsession.

В качестве примера смотрите .xsession ниже, ssh-agent стартует только при наличии в домашней директории пользователя поддиректории .ssh.

#!/bin/sh
if [ -d $HOME/.ssh ]
   then EXEC="exec ssh-agent"
   else EXEC="exec"
fi
if [ -x $HOME/.xinitrc ]
   then $EXEC $HOME/.xinitrc
   else $EXEC xterm -geometry 80x24+0-60 -ls
fi

unix1% chmod a+x ~/.xinitrc ~/.xsession

Важное: все изложенное не может быть применено к X-terminal'у который остается узким местом в безопасности вашей системы и сети.

Управление ключами авторизации в памяти.

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

unix1% ssh-add
 Need passphrase for /home/lavr/.ssh/identity (lavr@unix1.jinr.dubna.su).
 Enter passphrase: pust' vsegda 2000
 Identity added: /home/lavr/.ssh/identity (lavr@unix1.jinr.dubna.su)

Опция -d позволяет удалять ключи из памяти, не забудьте что в SSH нет команды "ssh-delete".

unix1% ssh-add -d ~/.ssh/isp

unix1% ssh-add -l
 1024 33 [lots of numbers] lavr@unix1.jinr.dubna.su

unix1% ssh-add -D

Запуск команд на удаленной системе.

Команда ssh может оказаться удобной для использования запуска программ или команд на удаленной системе без осуществления интерактивного входа на нее. Результат действия которых - вывод, может быть отображен и управляться на локальной системе. Ниже приведен подобный пример:

unix1% ssh cv who
 ckoch    tty03   Jun 30 14:09
 lavr     ttyp0   Jun 30 11:21   (cv.jinr.dubna.su)
 shchepun ttyp1   Jun 30 14:21   (axpls7.lns.infn.)
 grom     ttyp2   Jun 29 15:27   (unix0.jinr.dubna)
 veron    ttyp3   Jun 30 13:32   (159.93.22.23)
 ruben    ttyp4   Jun 30 13:29   (159.93.17.40)
 grom     ttyp5   Jun 30 12:32   (unix0.jinr.dubna)
 luna     ttyp6   Jun 30 11:38   (dct160.jinr.dubn)
 annask   ttypa   Jun 30 13:40   (xct174:0.0)
 vvm      ttypb   Jun 29 16:18   (cv.jinr.dubna.su)
 smanosh  ttypd   Jun 30 14:03   (bcv.jinr.dubna.s)
unix1%

unix1% ssh -n cv xterm & [1] 15866
unix1%

Копирование файлов между системами.

Вы можете копировать файлы между локальной и удаленной системами или между двумя удаленными системами используя команду scp и все это не требует какого либо вашего присутствия на удаленной системе. Для указания файла на удаленной машине достаточно лишь перед именем файла указать имя удаленной маштны и отделить от файла двоеточием, host:filename.

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

unix1% scp -p spp:dead.letter .
unix1%

unix1% scp -r cv:source src
unix1%

Можно также отметить еще ряд полезных ключей:

-C - копирование с компрессией, понятно что нет смысла использовать данную опцию для копирования уже сжатых данных.

-v - как и в остальных утилитах ssh[slogin] служит для вывода отладочной информации.

Необходимо заметить что относительные имена на локальной и удаленной системах разрешаются по разному:

• на локальной за базу принимается текущая директория
• на удаленной за базу принимается домашняя директория пользователя

unix1% scp bcv:ftptmp/ftp.out spp:temp/ftp.out.bcv
unix1%

            удаленную, копирование происходит непосредственно между теми двумя
            машинами без участия локальной.

Значения по умолчанию могут устанавливаться и изменяться каждым пользователем в файле $HOME/.ssh/config в дополнение или альтернативу системному файлу - /etc/ssh_config.
Каждая строка в конфигурации начинается с ключего слова HOST. Для задания общих значений можно использовать образцы соответствия:

• * ? соответсвует любому символу
• * * соответствует пустой или последовательности любого количества символов

 Compression yes/no (yes)
       использование компрессии в соединениях CompressionLevel 1-9 (6)
       уровень сжатия: 1 - самый быстрый, 9 - самый медленный (достигается
       максимальная компрессия), имеет смысл использовать на медленных соединениях
 FallBackToRsh yes/no (yes)
       если не удается установить секретное соединение с использованием SSH,
       пытаться перейти на использование Rsh, в системах со строгим соблюдением
       секретности данная опция отключается
 KeepAlive yes/no (yes)
       Управляет использование сообщения TCP keepalive. Когда используется,
       позволяет определять наличие связи в сети и автоматически закрывать
       соединение при обрыве или потере соединения.
 User account (local account)
       Укзывает имя на удаленной системе. Можете добавить эту характеристику
       вместо использования опции -l.

Ниже пример файла ~/.ssh/config.

Host nusun.jinr.ru
User lavr Compression no

Host sunhe.jinr.ru
User lavr CompressionLevel 6
FallBackToRsh no
KeepAlive yes

Host *
Compression yes CompressionLevel 9
FallBackToRsh yes
KeepAlive no

Не забывайте, что host-зависимые переменные следует определять до задания остальных - общих параметров (по-умолчанию), те, общие параметры для ssh укажите в самом конце конфигурационного файла, а выше задайте конкретные и специфические значения для индивидуальных host'ов и подсетей.

Из верхнего примера видно, что для всех hosts приписывается работать со сжатием данных - уровень 9, с переходом на rsh и без keepalive. И тем не менее с nusun работать под account=lavr, с sunhe с более быстрой компрессией и сваливанием на rsh ибо там отключен sshd и проверкой связи.

Для изучения полного списка опций и возможностей читайте руководство по ssh/sshd.

Автостарт ssh-agent с CDE.

Одно из неудобств может быть связано с запуском сеансов из CDE через ssh-agent, ниже приведем возможные решения:

• Первый способ:
  • необходимо иметь root-привелегии, выполним команду: su root

  • теперь выполним команду: cd /usr/dt/bin

  • выполним команду: mv Xsession XsessionA

  • создадим файл 0005.ssh-addkey

  • проверьте чтобы созданные файлы имели права на исполнения 0755

  Необходимые файлы-правки, приведены ниже:

  1. Новый файл Xsession, ssh-agent стартует в том случае, если пользователей сгенерировал ключи командой ssh-keygen, те существует файл $HOME/.ssh/identity.

  ------------------------------ Xsession ---------------------------------------
  #!/bin/ksh
  #
  # This script starts ssh-agent if there is a defined $HOME/.ssh/identity
  # file.
  #
  
  if [ -f $HOME/.ssh/identity -a -x /usr/local/bin/ssh-agent ] ; then
    /usr/local/bin/ssh-agent /usr/dt/bin/XsessionA
  else
    /usr/dt/bin/XsessionA
  
  fi
  --------------------------- end of Xsession -----------------------------------
  

  Итак, имеем запущеный ssh-agent для всей сессии, теперь добавление identity или считывание со стандартного ввода passphrase, для ввода пароль-фразы, ssh-add необходимо запустить с опцией -p:

  В зависимости от того как у вас установлен CDE, добавьте файл 0005.LOCAL.ssh либо в директорию /etc/dt/config/Xsession.d/, либо в /usr/dt/config/Xsession.d/

  2. Стартовый файл 0005.LOCAL.ssh:

  ---------------------------- 0005.ssh-addkey ----------------------------------
  #!/bin/ksh
  #
  if [ x$SSH_AUTHENTICATION_FD != x -o x$SSH_AUTHENTICATION_SOCKET != x \
       -a -x /usr/local/bin/ssh-add ]
  then
    /usr/local/bin/ssh-add
  fi
  ------------------------- end of 0005.ssh-addkey ------------------------------
  

• Второй способ:

  Все по пунктам, полностью работоспособен.

  • 1. Редактируем /usr/dt/config/Xconfig, добавляем строку:

         Dtlogin*session:              /usr/dt/bin/start.Xsession
    

  • 2. Создаем файл /usr/dt/bin/start.Xsession:

    ---------------------------- start.Xsession -----------------------------------
    #!/bin/ksh
     if [ -f $HOME/.ssh/identity -a -x /usr/local/bin/ssh-agent ] ;
       then
           exec /usr/local/bin/ssh-agent /usr/dt/bin/Xsession "$@"
       else
           exec /usr/dt/bin/Xsession
     fi
    ------------------------- end of start.Xsession -------------------------------
     3. Создаем файл /usr/dt/config/Xsession.d:
    ------------------------------ Xsession.d -------------------------------------
    #!/bin/ksh
    # The following is needed if ssh-add can't find ssh-askpass:
    
    PATH=$PATH:/usr/local/bin
    
     if [ "$SSH_AGENT_PID" -a -x /usr/local/bin/ssh-add ] ;
     then
        /usr/local/bin/ssh-add < /dev/null
     fi
    --------------------------- end of Xsession.d ---------------------------------
     4. Отредактируйте файл /usr/dt/config/C/Xresources:
    измените строку:
    
         Dtlogin*altDtStart1:          /usr/dt/bin/Xsession
    на
    
         Dtlogin*altDtStart1:          /usr/dt/bin/start.Xsession
    
     Иконку DtLogo.pm поместите в /usr/dt/appconfig/icons/C/
    а в файл ресурсов /usr/dt/config/C/Xresources можете добавить
    строку:
         Dtlogin*logo*bitmapFile:      /usr/dt/appconfig/icons/C/DtLogo.pm
    
     можете скачать иконку DtLogo.pm
    

SSH и туннелинг.

С помощью SSH можно устроить тунеллинг практически для любых TCP сессий, в отличие от UDP. Например может оказаться очень полезно использовать тунеллинг для POP/SMTP/FTP или PPP. Здесь данный пункт является чисто информативным, более подробную информацию можно найти в SSH-FAQ или в документации.

Всего лишь пара примеров: ssh -L 25:smtp.target.domain:25 target &
туннелинг для SMTP

1. myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server 2. 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 с машины myhost на машину ftphost Этот метод неудобен тем что для работы на локальной машине myhost, необходимо иметь два открытых окна, первое сам redirect пункт 1., а второе непосредственно для запуска ftp-client.

Примечание: Для более полной информации читайте SSH-FAQ. Отмечу лишь что имеются готовые реализации для работы по ftp:

• SafeTP - клиент-сервер для большого набора систем.
• sftp - клиент на базе установленного SSH, только для OS Unix'es

Возможные проблемы.

В первую очередь попробуйте прочитать SSH-FAQ, если это не помогло в решении ваших проблем, попробуйте поискать ответ в mail-архивах ssh, в ином случае сообщите разработчикам об обнаруженных вами bugs.

Тем не менее воспользуйтесь советом:

1. Для чистоты эксперимента, убедитесь в том что у вас больше нет открытых сеансов с ssh на других рабочих местах
2. Проверьте сгенерили ли вы ключи на вашем рабочем месте.
3. Проверьте наличие SSH демона на удаленной стороне.
4. Проверьте, не является ли ваша HOME-DIR объединенной по NFS для разных машин и как и для какой из них вы сгенерили ключи, и какую из них вы используете как локальное рабочее место.
5. Иногда демон sshd впадает в ступор, подмечено на Solaris - помогает `kill -HUP sshd-process-id`
6. Иногда происходит проблема авторизации из-за неотслеженных тонкостей при компиляции SSH c X-Window, когда в системе имеется например два GUI: OPENWIN и X-Window[X11R[N]. Видимо получается неверный .Xauthority, может помочь его удаление и/или затем создание его с нулевым размером.

Клиенты SSH для Windows.

Примечание: Этот пункт я сделаю позже, честно признаюсь - незнаю когда. К сожалению у меня не хватает техники для экспериментов с OS Unix, а для Windows мне уж точно не дадут PC.

Пока можно найти полезные ссылки здесь:

• Ссылки на ресурсы SSH для различных OS

Ссылки на другие полезные источники информации

1. Так сказать АВТОРА на сцену
2. Автор шикарного творения имеет право заработать
3. F-Secure - коммерческая реализация для MS Windows
4. Указатель ресурсов SSH.
5. Свободная версия SSH.

Партнёры:

Хостинг: