Ssh port forwarding — example, command, server config

Формат файла ssh_known_hosts

В файлах /etc/ssh/ssh_known_hosts и ~/.ssh/known_hosts хранятся открытые ключи всех машин, с которыми когда-либо устанавливалась связь. Глобальный файл должен быть подготовлен администратором (это необязательно), пользовательский файл поддерживается автоматически: каждый раз, когда поступает запрос на соединение от неизвестной машины, её ключ автоматически заносится в пользовательский файл.

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

Имена хостов — это разделённый запятыми список шаблонов (символы подстановки — «*» и «?»); каждый шаблон сопоставляется с каноническим именем машины (при аутентификации клиента) или с именем, которое указано пользователем (при аутентификации сервера). Этот шаблон может также быть предварён знаком «!» для обозначения отрицания: если имя машины соответствует отрицаемому шаблону, оно будет отвергнуто (этой строкой) даже если оно соответствует другому шаблону в этой же строке. Также можно, заключив имя хоста или IP-адрес в квадратные скобки «» и «», через «» указать нестандартный порт.

Вместо имён хостов можно записывать их хэши. Это позволит скрыть их от злоумышленника в случае попадания файла в его руки. Для различия хэшей от имён хостов первые предваряются символом «|». На одной строке может быть не больше одного хэша, операция отрицания в этом случае не доступна.

Разрядность, порядок и модуль копируются из ключа хоста RSA, например, /etc/ssh/ssh_host_key.pub. Необязательное поле комментария занимает всю оставшуюся часть строки и игнорируется.

Комментариями также считаются пустые и строки начинающиеся с «#».

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

Примечание! Заметьте, что строки в этих файлах, обычно имеют длину в несколько сотен символов и, очевидно, не стоит вводить имена хостов вручную. Вместо этого их можно сгенерировать при помощи сценария оболочки или взять из файла /etc/ssh/ssh_host_key.pub, добавив в начале имя хоста.

Пример файла ssh_known_hosts:

# допустимы явные комментарии только на всю строку
closenet       192.0.2.53 1024 37 159...93 closenet.example.net
cvs.example.net,192.0.2.10 ssh-rsa AAAA1234 =
# хэш имени хоста
|1|JfKTdBh7rNbXkVAQCRp4OQoPfmI=|USECr3SWf1JUPsms5AqfD5QfxkM= ssh-rsa
AAAA1234 =

Хеширование (hashing)

Еще один вид криптографических манипуляций с данными, который используется в SSH. Функция хеширования – метод создания короткой «подписи» или некая сумма данных. Основное свойство хеша заключается в его необратимости. Из него невозможно получить те данные, над которыми была выполнена функция хеширования. А еще он уникален для каждого набора данных (файла, строки, объекта…)

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

Благодаря данному свойству, хеши, в основном, используются для верификации. Главное применение в SSH – HMAC – hash-based message authentication code (проверка подлинности сообщений при помощи хеширования). Для того чтобы убедиться, что полученное сообщение не было изменено в процессе передачи.

Алгоритм HMAC выбирается точно так же, как и алгоритм симметричного шифрования, из списка, в процессе выбора симметричного шифрования, о чем говорилось ранее. Первый поддерживаемый сервером используется для соединения.

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

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

Подключение по SSH к хосту в VPN

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

Предположим, я хочу подключиться по SSH к компьютеру, который находится в VPN к которой я также подключён. В этом случае я могу подключиться указав IP интересующего меня компьютера в VPN сети, например:

ssh root@10.8.0.1

Некоторую дополнительную информацию смотрите .

Ссылки[править | править код]

Стандарты

RFC4251. The Secure Shell (SSH) Protocol Architecture (англ.)

Программы терминального доступа

• OpenSSH — свободная библиотека и набор утилит для поддержки шифрования, открытый код
• Сравнение SSH-клиентов (англ.)
• MidpSSH (англ.) — SSH-клиент для мобильных телефонов

Программы доступа к файлам

• FTP Commander Deluxe — популярная программа поддерживает все безопасные протоколы

Прочее

• Защита SSH в GNU/Linux от взлома
• Краткое введение в SSH
• Сравнение SSH-клиентов
• PuTTY под Windows
• Работаем с PuTTY из Windows
• Теория и практика использования SSH
• SSH в Windows
• Analyzing Malicious SSH Login Attеmpts

Динамическая переадресация портов

Динамическая переадресация портов позволяет создать сокет на локальном (ssh-клиентском) компьютере, который действует как прокси-сервер SOCKS. Когда клиент подключается к этому порту, соединение перенаправляется на удаленный компьютер (сервер ssh), который затем перенаправляется на динамический порт на конечном компьютере.

Таким образом, все приложения, использующие прокси-сервер SOCKS, будут подключаться к серверу SSH, и сервер будет перенаправлять весь трафик в его фактическое место назначения.

В Linux, macOS и других системах Unix для создания динамической переадресации портов (SOCKS) передайте параметр клиенту :

Используются следующие параметры:

• — IP-адрес и номер порта локального компьютера. Если опущен, клиент ssh привязывается к localhost.
• — удаленный пользователь SSH и IP-адрес сервера.

Типичным примером динамической переадресации портов является туннелирование трафика веб-браузера через SSH-сервер.

Следующая команда создаст туннель SOCKS на порту :

Перенаправление портов должно быть настроено отдельно для каждого приложения, которое вы хотите туннелировать трафик через него.

Алиасы

Алиасы — сокращенные формы команд. Заметно экономят время и улучшают восприятие. Особенно когда в алиасах прячутся громоздкие скрипты. backupmsql выглядит проще и легче запоминается, чем mysqldump -u имя учетной записи -p пароль от учетной записи -D название базы данных < путь до базы данных.

Процедура создания алиаса сводится к следующему синтаксису: alias сокращение=‘команда, которую надо сократить’

Например: alias supd=‘sudo apt-get update’. Теперь обновлять информацию о пакетах можно сокращенной версией команды.

Полезные алиасы

Далее последуют алиасы, которые часто используются начинающими линуксоводами и администраторами:

alias h=‘history’ — для вызова истории вводом одной буквы. Алиас можно немного усложнить, добавив какое-либо числовое значение. Допустим, сделать alias h25=‘history 25’, чтобы вывести в консоль сразу 25 предыдущих команд.

alias diff=‘colordiff’ — добавляет цвет, чтобы элементы сравнения легче было распознавать.

alias edit=’sudo nano’ — упрощает доступ к редактированию текста от имени администратора.

alias ping=‘ping -c 5’ — уменьшает количество пакетов, передаваемых через Ping, до 5 штук.

alias update=’sudo apt-get update && sudo apt-get upgrade’ — сокращение, помогающее сначала обновить информацию о пакетах, а потом установить свежие версии с помощью одной короткой команды вместо двух больших. Только в случае с другими дистрибутивами надо скорректировать обе, заменив наименования пакетных менеджеров. Для Fedora это будет dnf, к примеру.

alias backup=’sudo /home/scripts/admin/scripts/backup/wrapper.backup.sh –type local –target /raid1/backups’ — запускает скрипт, который автоматически создает резервную копию пользовательских данных.

alias restart=‘ssh admin@192.168.1.1 /sbin/reboot’ — подключается к роутеру через SSH и перезапускает его.

Навигация

Вывод текущей рабочей директории

Для вывода информации о текущей рабочей директории используется команда pwd.

Пример использования:

username@server:~$ pwd
/home/u/username

Вывод содержимого директории

Чтобы посмотреть содержимое директории, воспользуйтесь командой ls.

Вывод содержимого текущей директории в несколько колонок (только имена файлов и директорий):

ls .

Вывод содержимого текущей директории в одну колонку (только имена файлов и директорий):

ls -1

Вывод подробной информации о содержимом текущей директории, включая скрытые файлы (имя которых начинается с точки):

ls -la

Вывод содержимого конкретной директории:

ls имя_директории

Пример использования:

username@server:~$ ls -la
total 16
drwx------  4 username customers 4096 Mar 10 12:56 .
drwx------ 14 username customers 4096 Mar 10 12:55 ..
-rw-------  1 username customers    0 Mar 10 12:56 .htaccess
drwx------  2 username customers 4096 Mar 10 12:55 test
drwx------  2 username customers 4096 Mar 10 12:55 test1
-rw-------  1 username customers    0 Mar 10 12:55 test.txt
где "." - текущий каталог, а ".." - родительский каталог.

Перемещение между директориями

Команда cd позволяет выполнить переход в другую директорию.

Основные способы применения:

Перейти в директорию, которая находится в текущей директории:

cd dirname

Перейти в родительский каталог (на уровень выше):

cd ..

Перейти в домашний каталог:

cd
 
# Либо:
 
cd ~

Перейти в домашний каталог по абсолютному пути (начиная с корня):

cd /home/u/username

Перейти в предыдущий каталог:

cd -

Примеры использования:

# Текущая директория отображается после двоеточия и до символа "$".
 
# Перейти в каталог media
username@server:~$ cd /home/u/username/public_html/media
 
# Перейти в каталог cms
username@server:~/public_html/media$ cd cms
 
# Перейти в домашний каталог
username@server:~/public_html/media/cms$ cd
 
# Перейти в предыдущий каталог
username@server:~$ cd -
/home/u/username/public_html/media/cms
 
# Перейти на уровень выше
username@server:~/public_html/media/cms$ cd ..
username@server:~/public_html/media$

The story of getting SSH port 22

I wrote the initial version of SSH (Secure Shell) in Spring 1995. It was a time when telnet and FTP were widely used.

Anyway, I designed SSH to replace both (port 23) and (port 21). Port 22 was free. It was conveniently between the ports for and . I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port.

The basic process for port allocation was fairly simple at that time. Internet was smaller and we were in the very early stages of the Internet boom. Port numbers were allocated by IANA (Internet Assigned Numbers Authority). At the time, that meant an esteemed Internet pioneer called Jon Postel and Joyce K. Reynolds. Among other things, Jon had been the editor of such minor protocol standards as IP (RFC 791), ICMP (RFC 792), and TCP (RFC 793). Some of you may have heard of them.

To me Jon felt outright scary, having authored all the main Internet RFCs!

There we were! SSH port was 22!!!

On July 12, 1995, at 2:32am, I announced a final beta version to my beta testers at Helsinki University of Technology. At 5:23pm I announced ssh-1.0.0 packages to my beta testers. At 5:51pm on July 12, 1995, I sent an announcement about SSH (Secure Shell) to the mailing list. I also posted it to a few newsgroups, mailing lists, and directly to selected people who had discussed related topics on the Internet.

Советы по безопасности использования SSH

1. Запрет на удалённый root-доступ.
2. Запрет подключения с пустым паролем или отключение входа по паролю.
3. Выбор нестандартного порта для SSH-сервера.
4. Использование длинных SSH2 RSA-ключей (2048 бит и более). Системы шифрования на основе RSA считаются надёжными, если длина ключа не менее 1024 бит.
5. Ограничение списка IP-адресов, с которых разрешён доступ (например, настройкой файервола).
6. Запрещение доступа с некоторых потенциально опасных адресов.
7. Отказ от использования распространённых или широко известных системных логинов для доступа по SSH.
8. Регулярный просмотр сообщений об ошибках аутентификации.
9. Установка систем обнаружения вторжений (IDS).[источник не указан 756 дней]
10. Использование ловушек, подделывающих SSH-сервис (honeypot).
11. Реализация технологии

Примеры использования SSH

Команда подключения к локальному SSH-серверу из командной строки GNU/Linux или FreeBSD для пользователя pacify (сервер прослушивает нестандартный порт 30000):

$ ssh -p 30000 pacify@127.0.0.1

Генерация пары ключей (в UNIX-подобных ОС) осуществляется командой

$ ssh-keygen

Генерация пары SSH-2 RSA-ключей длиной 4096 бита программой puttygen под UNIX‐подобными ОС:

$ puttygen -t rsa -b 4096 -o sample

Некоторые клиенты, например, PuTTY, имеют и графический интерфейс пользователя.

Для использования SSH в Python существуют такие модули, как python-paramiko и python-twisted-conch.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

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

ssh user@192.168.1.2

ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:abcde/accdefghijkld9UNaDBnnUHanJ9Svca9vFx7c.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3
ERROR: remove with:
ERROR: ssh-keygen -f «/home/user/.ssh/known_hosts» -R «192.168.1.2»
ERROR: ECDSA host key for 192.168.1.2 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Из строки

ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3

Можно понять, что проблема вызвана третьей строкой файла

/home/user/.ssh/known_hosts

Если вы уверены в надёжности хоста к которому подключаетесь, то
можете просто удалить эту строку и подключиться снова

sed -i 3d /home/$(whoami)/.ssh/known_hosts

ssh-keygen -R 192.168.1.2

В случае более сложных подключений, предупреждение может быть по поводу определённого порта

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:nN5D5mBv00vkinsOmKbaKN1o2dEVZj5BidWaKBY1LpA.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/username/.ssh/known_hosts:14
remove with:
ssh-keygen -f «/home/username/.ssh/known_hosts» -R «:1234»
ED25519 host key for :1234 has changed and you have requested strict checking.
Host key verification failed.

В этом случае подсказка по-прежнему содержится в предупреждении (выделил её зелёным).

Выполните

ssh-keygen -f «/home/username/.ssh/known_hosts» -R «:1234»

# Host :1234 found: line 14
/home/username/.ssh/known_hosts updated.
Original contents retained as /home/username/.ssh/known_hosts.old

Что такое SSH

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

На рисунке ниже показано обычное окно SSH. Любой пользователь Linux или macOS может воспользоваться SSH напрямую из окна терминала. Пользователи Windows могут воспользоваться SSH-клиентом вроде Putty. Вы можете выполнять shell команды также, как если бы вы напрямую управляли удаленным компьютером.

Это руководство по SSH расскажет о том, что такое SSH, как работает SSH и заодно поможет вам понять технологии позволяющие протоколу предоставлять защищенное удаленное управление. Мы подробнее остановимся на каждом из слоёв и типов шифрования, а также расскажем о значении каждого из них.

Как пользоваться PuTTY

1. Интерфейс программы

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

Рассмотрим за что отвечают те или иные вкладки программы, чтобы вы ориентировались что и где искать. У нас есть четыре вкладки:

• Session — отвечает за подключение удаленному серверу, тут мы вводим параметры подключения, порт, адрес, а также можем сохранить все настройки putty, чтобы не настраивать каждый раз заново.
• Terminal — позволяет включать или отключать возможности терминала;
• Window — настройка внешнего вида окна, цвет, шрифт, кодировка;
• Connection — настройка параметров подключения, алгоритма шифрования, сжатия, ключей аутентификации, X11 и других параметров.

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

2. Подключение к удаленному компьютеру PuTTY

Чтобы подключиться к удаленному компьютеру по SSH перейдите на вкладку «Session», здесь, в поле «Host Name» необходимо прописать ip адрес или имя хоста, компьютера, к которому вы хотите подключиться, в поле порт — нужно указать порт, на котором запущен SSH сервер, по умолчанию используется порт 22:

Далее, нажмите кнопку «Open». После этого появится запрос на добавление ключа сервера в список доверенных ключей, нажмите «Да»:

Затем вам будет нужно ввести логин пользователя и пароль

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

Теперь авторизация прошла успешно, и вы можете выполнять нужные действия на сервере:

3. Сохранение сессии PuTTY

Чтобы не вводить каждый раз ip и порт можно сохранить эти данные в виде сессии, для этого пропишите новое имя в поле «Saved Sessions», а затем нажмите кнопку «Save»:

Теперь вы сможете загрузить сохраненную сессию, нажав кнопку «Load».

После того как будет завершена настройка putty и все параметры будут выставлены правильно вы можете сохранить настройки и не вводить их несколько раз.

4. Имя пользователя по умолчанию

Вы можете не вводить имя пользователя каждый раз, для этого перейдите на влкадку «Connection», затем «Data» и в поле «Auto-login Username» пропишите имя пользователя, например, root:

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

5. Авторизация по ключу ssh в PuTTY

Чтобы не вводить каждый раз пароль можно настроить авторизацию по ключу. В Linux такая возможность используется очень широко потому что это удобно. Первым делом необходимо создать ключ. Для этого запустите утилиту PuTTYgen и установите переключатель в положение «SSH-2 RSA» нажмите «Generate»:

Обязательно ключ должен быть SSH-2 RSA, если в главном окне нет, выберите в меню «Key». Подвигайте мышкой, чтобы создать достаточное количество энтропии:

Ключ готов, затем, с помощью кнопок «Save Public Key» и «Save Private Key» сохраните оба ключа.

Далее, откройте PuTTY, перейдите на вкладку «Connection», затем «SSH», затем «Auth»:

Здесь необходимо нажать кнопку «Browse» и добавить недавно сохраненный приватный ключ:

Далее, возвращаемся на вкладку «Session», выбираем наше сохранение и нажимаем «Save» чтобы сохранить настройки. Осталось только отправить наш открытый ключ на сервер. Для этого авторизуйтесь на нем с помощью пароля и открытый ключ вставьте ключ в конец файла /root/.ssh/authorized_keys.

Ключ можно брать прямо из окна PuTTYgen «Public key for pasting» или из файла открытого ключа:

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

5. Передача файлов через scp в PuTTY

Не все знают, но PuTTY позволяет передавать файлы через ssh также как это делает linux с помощью утилиты scp. Нажмите Win+R, затем пропишите cmd, чтобы запустить командную строку.

Синтаксис утилиты pcsp выглядит следующим образом:

pscp опции путь_файлу имя_пользователя@хост/путь/к/файлу/на/удаленном/хосте

Например, мы можем отправить файл из текущей папки в папку пользователя /root/:

С помощью опции -P можно задать удаленный порт:

А опция load позволяет загрузить сохраенные настройки сессии PuTTY:

Теперь вы знаете как использовать putty для передачи файлов.

Аутентификация

Служба OpenSSH SSH поддерживает версии протокола SSH 1 и 2. Запретить использование одного из протоколов можно, указав в параметре Protocol файла sshd_config. Протокол 2 поддерживает ключи RSA и DSA; протокол 1 поддерживает только ключи RSA. Независимо от протокола, каждый подключающийся хост имеет собственный (обычно 2048-битный) идентифицирующий его ключ.

Для протокола версии 1 подтверждение субъекта сервера обеспечивается 768-битным ключом, который генерируется при запуске сервера. Ключ генерируется заново каждый час, при условии его использования, и не хранится на диске. При получении запроса на подключение со стороны клиента служба посылает в ответ свой открытый ключ и свои ключи. Клиент сравнивает ключ хоста RSA со своими данными, чтобы убедиться в том, что это тот же сервер. Затем клиент генерирует 256-битное произвольное число, шифрует его при помощи обоих ключей (своего и сервера) и отправляет результат серверу. Это число становится ключом сеанса, и с его помощью выполняется кодирование всей последующих данных, по согласованному методу — Blowfish или 3DES (клиент выбирает метод из предложенных сервером). В настоящее время по умолчанию используется 3DES.

Для протокола версии 2 подтверждение субъекта сервера обеспечивается по схеме Диффи—Хеллмана, в результате которой также получается общий ключ сеанса. Дальнейший обмен данными шифруется симметричным кодом, 128-битным AES, Blowfish, 3DES, CAST128, Arcfour, 192-битным AES или 256-битным AES, который выбирает клиент из предложенных сервером. Кроме того, целостность передаваемых данных обеспечивается кодом подтверждения подлинности сообщения (hmac-sha1 или hmac-md5).

Далее сервер и клиент переходят в режим аутентификации. Клиент пытается аутентифицировать себя по своему хосту, открытому ключу, паролю или с помощью беспарольного механизма («вызов-ответ»).

Независимо от типа аутентификации, служба проверяет доступность соответствующей учётной записи в системе. Так, она может быть заблокирована посредством добавления её в параметр DenyUsers или её группы в DenyGroups. Механизм общесистемной блокировки учётной записи выполняется разными системами по-разному. Одни системы ведут собственную базу данных учётных записей (AIX), другие вносят соответствующие изменения в поля файла passwd («*LK*» — Solaris и UnixWare, «*» — на HP-UX, «Nologin» — Tru64, «*LOCKED*» во FreeBSD и «!!» в GNU/Linux). Для запрета только аутентификации по паролю укажите в файле passwd «NP» или «*NP*».

После успешной аутентификации себя клиентом связь переходит в режим подготовки сеанса. В этот момент клиент может запросить такие вещи, как выделение псевдо-терминала, перенаправление соединения Х11, перенаправление соединения TCP/IP или перенаправление соединения агента аутентификации через защищённый канал.

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

По завершении работы пользовательской программы и закрытии всех перенаправленных Х11 и других соединений сервер посылает клиенту команду со статусом выхода и сеанс завершается.