Руководство по настройке и использованию SSH

Вступление.

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

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

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

запуск системы X11 на локальном дисплее.
запуск системы X11 через сессию xdm.

Управление ключами авторизации в памяти.
Запуск команд на удаленной системе.
Копирование файлов между системами.
Изменение стандартных настроек.
Автостарт ssh-agent с CDE.
SSH и туннелинг.
Возможные проблемы.
Клиенты SSH для Windows.
Ссылки на другие полезные источники информации.

Коротко о работе SSH.

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

Client выступает в качестве рабочего места пользователя, на нем обязательно должны быть сгенерены "public key" и "private key", а со стороны удаленной машины, куда мы хотим иметь безопасный вход, должен быть запущен демон SSHD, таким образом удаленная машина является сервером - Server.

Если пользователь в качестве 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%

Если вы имеете несколько accounts (входов в разные системы), то можете создать несколько отдельных и разных ключей для каждого из них, например:

для оффиса
для личной системы
для 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

Теперь вы можете скопировать файл authorized_keys на другие удаленные системы чтобы позволить доступ к ним с локальной системы. Передать это файл вы можете по ftp или через rcp/scp.
При появлении доступа к новым или закрытия к старым системам вы можете изменять соответственно ваш файл authorized_keys используя текстовый редактор. Помните, что каждый ключ - это одна строка файла, а также то что добавляемые вами ключи всегда "public key" из файлов с расширением pub.

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

Если после всех проделанных мероприятий, удаленная система отказывает вам в доступе, попробуйте проверить права и доступ к директориям и файлам связанным с 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%

Запомните, проделав эту процедуру на всех система вы получите полный доступ ко всем вашим accounts.

Примечание:

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

Строго говоря, личный ключ - файл 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

^^^^^^^^^^^^^^- в чем мы можем убедиться, в отличии например от машины sungraph

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 сохранив до этого ключи аутентикации в памяти. Но все равно вы будете вынуждены ввести passphrase, но лишь однажды, когда будете добавлять их в память. (см. использование ssh-add)

Примечание: Иногда запрос на аутентикацию посредством 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в фоновом режиме, при котором остается возможностьпродолжать использовать для работы ту консоль с которой мы стартовали X-Window, независимо от них.

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

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

Первый способ состоит в том что пользователя заставляют в принудительном порядке стартовать оконную среду ичсключительно с использованием ssh-agent. Здесь можно придумать массу разнообразных вариантов со своими плюсами и минусами, например создание alias на команду startx во входных скриптах:

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%

На моих серверах пользователи в основном используют в качестве SHELL: sh,bash,csh,tcsh, я как и большая масса системных администраторов заменяю стандартные скрипты, которые обычно находятся в директории /etc/skel или в зависимости от системы в иной директории на болванки с одной строкой-вызовом скриптов доработанных и проверенных системным администратором, в которые и вставляется alias на startx.

Примеры:

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

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%

вырезки из /usr/local/etc/.bashrc и /usr/local/etc/.cshrc[.login] соответственно (почему указан .login надеюсь понятно)

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%

Соответствующие изменения производятся и с системныи xinitrc в который добавляется проверка на собственно аутентикацию.

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

Указанная выше строка должна запускаться до инициализации X-clients и вызова оконного менеджера.

----------------------- 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 ----------------------------

Минусы[и плюсы] этого способа в том что пользователь может использовать только свои входные настройки среды - имеет право, и соответственно свой .xinitrc.

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

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

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

unix1% mv startx startX

А startx изображаем следующим образом:

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

Соответствующие дополнения вносим и в системный xinitrc до старта x-clients и оконного менеджера

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

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

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

Далее вставить строку "until ssh-askpass | ssh-add -p; do true; done" в свой .xinitrc, в нужное место, описано выше и в зависимости от используемого SHELL вставить alias на вызов startx, описано выше.

Будьте аккуратны, все вышеизложенное касается запуска 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

Примечание: если ваш администратор не позаботился об настройках системы вам достаточно настроить свои файлы .xinitrc и .xsession, однако если в вашей системе X-Window запускается иным - нестандартным способом лучше всегообратититься к системному администратору. На мой взгляд лучше заранее обратиться к администратору и выяснить все вопросы и это касается любой темы, не только безопасности системы.

Важное: все изложенное не может быть применено к 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)

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

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

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

Получить список всех текущих ключей в памяти - опция -l.

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

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

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%

Если вы работаете в X-Window System, то можете запустить xterm для получения интерактивного сеанса на удаленной машине:

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

Использование опции -n запрещает чтение со стандартного ввода (перенаправление с /dev/nul) и запускает ssh в фоновом режиме. Однако не стоит использовать данный метод запуска если удаленная сторона пытается запрашивать вас ввести passphrase или passowrd.

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

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

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

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

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

unix1% scp -r cv:source src
unix1%

В данном примере опция -r означает что необходимо рекурсивно скопировать директорию source расположенную на машине "cv" в директорию 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:

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

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

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

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

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

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

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

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

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

Copyleft Andrey Lavrentyev