SSH в Linux

Введение

SSH (англ. Secure Shell — «безопасная оболочка») — сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP-соединений (например, для передачи файлов).

Схож по функциональности с протоколами Telnet и rlogin, но, в отличие от них, шифрует весь трафик, включая и передаваемые пароли.

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

SSH позволяет безопасно передавать в незащищённой среде практически любой другой сетевой протокол. Таким образом, можно не только удалённо работать на компьютере через командную оболочку, но и передавать по шифрованному каналу звуковой поток или видео (например, с веб-камеры)[2]. Также SSH может использовать сжатие передаваемых данных для последующего их шифрования, что удобно, например, для удалённого запуска клиентов X Window System.

Большинство хостинг-провайдеров за определённую плату предоставляет клиентам доступ к их домашнему каталогу по SSH.

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

RFC 4251

Перед началом работы убедитесь, что сервис ssh включен и работает

Подробнее про SSH туннели можно прочитать в статье «SSH туннели»

Про сертификаты - в статье «SSH сертификаты»

Установка

В Ubuntu , Debian и т.д.

sudo apt -y install ssh

Включить/выключить/статус/перезапуск

sudo systemctl start|stop|status|restart sshd.service

Или если вы в Debian , Ubuntu и т.д.

sudo systemctl start|stop|status|restart ssh.service

Подключение по SSH

Подключение происходит с помощью команды ssh + имя_пользователя + адрес хоста

Например

ssh andrei@192.168.0.2

Можно явно указать ключ с помощью -i

ssh -i ~/.ssh/id_rsa andrei@192.168.0.2

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

The authenticity of host '192.168.56.101 (192.168.56.101)' can't be established. ECDSA key fingerprint is SHA256:db8az/qbrWOJWvNRv2d9UHaDBnnUHanJ9Svca9vFx7c. Are you sure you want to continue connecting (yes/no/[fingerprint])?

Если выбрать yes то в файл ~/.ssh/known_hosts добавится похожая строка:

|1|abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Если у вас на хосте не было директории .ssh после первого подключения она должна появится.

Сгенерировать пару ключей

Первый шаг - это генерация пары ключей. Обычно это делается на клиентской машине. Например, на вашем ноутбуке.

Основная команда ssh-keygen создаст 2048-битную пару RSA ключей. Для большей надёжности можно добавить флаг -b 4096

Выполните

ssh-keygen -b 4096

Чтобы сгенерировать ключ в /home/$(whoami)/.ssh

или

sudo ssh-keygen -b 4096

Чтобы сгенерировать ключ в /home/root/.ssh

Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa):

Нужно придумать имя ключа.

Я назову ключ andrei-key101 а сохранять буду в текущую директорию.

Enter file in which to save the key (/root/.ssh/id_rsa): andrei-key101 Enter passphrase (empty for no passphrase): Enter same passphrase again:

Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.

Your identification has been saved in andrei-key101 Your public key has been saved in andrei-key101.pub The key fingerprint is: SHA256:abcd/abcdefghijklmnopqrstuvwxyz1234567890ab root@urn-su The key's randomart image is: +---[RSA 4096]----+ |=o oo++ | |= oo o. = o | |+ | |Oo=o . . | |B+.o S . | |+o.o | |+.0. . | |o+= . E | |+=oo. . . | +----[SHA256]-----+

Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls

ls

andrei-key101 andrei-key101.pub

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

РЕКЛАМА хостинга Beget, которым я пользуюсь более десяти лет

Конец рекламы хостинга Beget, который я всем рекомендую.

Какой ключ куда?

.pub ключ отправляйте на удалённую машину

приватный ключ храните на своём клиенте

Передать ключ на удалённый хост

После того, как ключи созданы нужно передать .pub ключ на удалённый хост.

Сделать это можно несколькими способами начнём с утилиты ssh-copy-id

ssh-copy-id

Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа

sudo ssh-copy-id -i ~/.ssh/andrei-key.pub andrei@192.168.0.2

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/andrei/.ssh/andrei-key.pub" The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established. ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def. Are you sure you want to continue connecting (yes/no/[fingerprint])?

Введите yes

Are you sure you want to continue connecting (yes/no/[fingerprint])? yes /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys andrei@192.168.0.2's password:

Введите пароль

Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'andrei@192.168.0.2'" and check to make sure that only the key(s) you wanted were added.

Теперь на хосте 192.168.0.2 в файле /home/andrei/.ssh/authorized_keys появилась новая запись вида

ssh-rsa AAAAB3NzaC1y … lseP/jXcq … Uydr/2CwQ &hellip ++TpY19pHqD/AnhL … Az62T/Ipyx … 8U2T andrei@host.andrei.com

Знак … заменяет длинные последовательности случайных символов для экономии места.

Проверить ключ можно командой

ssh -i ~/.ssh/mykey user@host

В нашем случае

ssh -i ~/.ssh/andrei-key andrei@192.168.0.2

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

Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1

Добавить ключ вручную

Добиться подключения по ключу можно и без ssh-copy-id

Те же манипуляции можно проделать вручную.

id_rsa нужно поместить на клиенте в

/home/client/.ssh

А id_rsa.pub на сервере добавить в

/home/server/.ssh/authorized_keys

Если клиент первый и единственный, то можно просто скопировать ключ

cp id_rsa.pub /home/server/.ssh/authorized_keys

Если есть и другие клиенты, то надо дописывать в конец файла.

Узнать версию OpenSSH в Linux

Чтобы узнать версию OpenSSH в вашем дистрибутиве Linux выполните

ssh -V

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

Существующие версии OpenSSH можете изучить здесь

Выполнить команду из скрипта на удалённом компьютере

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

#!/bin/bash ssh andrei@192.168.0.2 "ls;cd /home/andrei/bash_scripts;ls;ip a;cal"

Если нужно выполнить команду, требующую sudo попробуйте флаг -t

#!/bin/bash ssh -t andrei@192.168.0.2 "sudo apt upgrade"

known_hosts

Список известных хостов находится в файле known_hosts

Полный путь:

/home/$(whoami)/.ssh/known_hosts

Обычно файл known_hosts имеет следующий формат (записи идут через пробел) ( подробнее )

{server-id} алгоритм {public-key-string} {comment}

Примеры алгоритмов: ssh-rsa, ssh-dss, ssh-ed25519, ecdsa-sha2-nistp256 …

Пример строки:

|1|abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Здесь через пробел записаны три элемента: хэш от имени сервера, название используемого ассиметричного алгоритма и публичный ключ сервера. Разберём их по очереди.

Таким образом

abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1=

Это хэш от имени сервера.

ssh-rsa

Это алгоритм шифрования

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Это публичный ключ хоста

Для freerdp соединений может существовать отдельный файл со списком хостов, например /home/andrei/.config/freerdp/known_hosts2

Чтобы удалить устаревшую запись по номеру строки (например 155) нужно выполнить

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

Чтобы очистить файл от записей о каком-то определённом хосте (например 192.168.56.109) нужно выполнить

ssh-keygen -R 192.168.56.109

Запустить SSH в фоновом режиме

Существует несколько способов запустить ssh соединение в фоновом режиме - то есть освободим текущий терминал.

-L, screen, tmux, nohup

Мне запустить ssh фоном из скрипта помог nohup, поэтому начнём с него

nohup ssh user@host "cd scripts;python3 my_script.py $ARG1 $ARG2; exit" &

Для чего это было нужно: Python скрипт сначала открывал одно ssh соединение из subprocess там выполнялась команда для запуска мониторинга потребления памяти и больше от этого соединения ничего было не нужно, зато необходимо было выполнять новые соединения с нагрузкой из другого скрипта.

Чтобы уйдя из первого подключения не оборвать мониторинг потребления памяти перед ssh нужно было добавить nohup, а в самом конце поставить &

SSH_CONNECTION

После того, как соединение установилось можно изучть его с помощью переменной $SSH_CONNECTION

echo $SSH_CONNECTION

192.168.56.1 51284 192.168.56.103 22

SSH_MSG_USERAUTH_BANNER

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

Спецификация rfc4252

Выполните

sudo vi /etc/issue.net

И отредактируйте файл добавив свой баннер

\S Kernel \r on an \m ######################################################### # ANDREYOLEGOVICH.RU and URN.SU # #########################################################

Откройте sshd_config и укажите путь до баннера

sudo vi /etc/ssh/sshd_config
/banner

# no default banner path #Banner none

Этот баннер будет показан ДО авторизации, то есть во время ввода пароля

Чтобы создать баннер, который будет показан после успешного входа выполните

sudo vi /etc/motd

######################################################### # YOU ARE HERE: devhops.ru/linux/ssh/ # #########################################################

После редактирования файлов перезапустите sshd

sudo systemctl restart sshd.service

Разрешить доступ по SSH в iptables

Чтобы явно разрешить доступ по ssh через iptables выполните

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

Проверить результат можно выполнив команду iptables -L и проверив появилось ли нужное правило.

iptables -L

…
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
…

Список подключений по SSH

Получить список установленных подключений можно с помощью команд netstat и grep указав порт (стандартный - 22) и

netstat -tnpa | grep 22 | grep ESTABLISHED

(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) tcp 0 0 10.15.252.125:22 10.1.55.58:56722 ESTABLISHED - tcp 0 0 10.15.252.125:22 10.15.253.192:47614 ESTABLISHED -

config

В директории

/home/username/.ssh

можно создать файл config с настройками для ssh клиента

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

Host mkdocs.andrei.com HostName mkdocs.andrei.com User jenkins IdentityFile ~/.ssh/jenkins_rsa # IdentitiesOnly yes Host nginx HostName nginx.andrei.com User jenkins IdentityFile ~/.ssh/jenkins_rsa IdentitiesOnly yes

С такими настройками вместо команды

ssh -i ~/.ssh/jenkins_rsa jenkins@nginx.andrei.com

Можно выполнить просто

ssh nginx

Существующие версии OpenSSH

OpenSSH 8.9/8.9p1 (2022-02-23) New features ------------ * ssh(1), sshd(8): use the hybrid Streamlined NTRU Prime + x25519 key exchange method by default ("sntrup761x25519-sha512@openssh.com"). The NTRU algorithm is believed to resist attacks enabled by future quantum computers and is paired with the X25519 ECDH key exchange (the previous default) as a backstop against any weaknesses in NTRU Prime that may be discovered in the future. The combination ensures that the hybrid exchange offers at least as good security as the status quo. We are making this change now (i.e. ahead of cryptographically- relevant quantum computers) to prevent "capture now, decrypt later" attacks where an adversary who can record and store SSH session ciphertext would be able to decrypt it once a sufficiently advanced quantum computer is available. * sftp-server(8): support the "copy-data" extension to allow server- side copying of files/data, following the design in draft-ietf-secsh-filexfer-extensions-00. bz2948 * sftp(1): add a "cp" command to allow the sftp client to perform server-side file copies. OpenSSH 8.8/8.8p1 (2021-09-26) New features ------------ * ssh(1): allow the ssh_config(5) CanonicalizePermittedCNAMEs directive to accept a "none" argument to specify the default behaviour. OpenSSH 8.7/8.7p1 (2021-08-20) New features ------------ - scp(1): experimental support for transfers using the SFTP protocol as a replacement for the venerable SCP/RCP protocol that it has traditionally used. SFTP offers more predictable filename handling and does not require expansion of glob(3) patterns via the shell on the remote side. SFTP support may be enabled via a temporary scp -s flag. It is intended for SFTP to become the default transfer mode in the near future, at which time the -s flag will be removed. The -O flag exists to force use of the original SCP/RCP protocol for cases where SFTP may be unavailable or incompatible. - sftp-server(8): add a protocol extension to support expansion of ~/ and ~user/ prefixed paths. This was added to support these paths when used by scp(1) while in SFTP mode. - ssh(1): add a ForkAfterAuthentication ssh_config(5) counterpart to the ssh(1) -f flag. GHPR231 - ssh(1): add a StdinNull directive to ssh_config(5) that allows the config file to do the same thing as -n does on the ssh(1) command- line. GHPR231 - ssh(1): add a SessionType directive to ssh_config, allowing the configuration file to offer equivalent control to the -N (no session) and -s (subsystem) command-line flags. GHPR231 - ssh-keygen(1): allowed signers files used by ssh-keygen(1) signatures now support listing key validity intervals alongside they key, and ssh-keygen(1) can optionally check during signature verification whether a specified time falls inside this interval. This feature is intended for use by git to support signing and verifying objects using ssh keys. - ssh-keygen(8): support printing of the full public key in a sshsig signature via a -Oprint-pubkey flag. OpenSSH 8.6/8.6p1 (2021-04-19) New features ------------ * sftp-server(8): add a new limits@openssh.com protocol extension that allows a client to discover various server limits, including maximum packet size and maximum read/write length. * sftp(1): use the new limits@openssh.com extension (when available) to select better transfer lengths in the client. * sshd(8): Add ModuliFile keyword to sshd_config to specify the location of the "moduli" file containing the groups for DH-GEX. * unit tests: Add a TEST_SSH_ELAPSED_TIMES environment variable to enable printing of the elapsed time in seconds of each test. OpenSSH 8.5/8.5p1 (2021-03-03) New features ------------ * ssh(1): this release enables UpdateHostkeys by default subject to some conservative preconditions: - The key was matched in the UserKnownHostsFile (and not in the GlobalKnownHostsFile). - The same key does not exist under another name. - A certificate host key is not in use. - known_hosts contains no matching wildcard hostname pattern. - VerifyHostKeyDNS is not enabled. - The default UserKnownHostsFile is in use. We expect some of these conditions will be modified or relaxed in future. * ssh(1), sshd(8): add a new LogVerbose configuration directive for that allows forcing maximum debug logging by file/function/line pattern-lists. * ssh(1): when prompting the user to accept a new hostkey, display any other host names/addresses already associated with the key. * ssh(1): allow UserKnownHostsFile=none to indicate that no known_hosts file should be used to identify host keys. * ssh(1): add a ssh_config KnownHostsCommand option that allows the client to obtain known_hosts data from a command in addition to the usual files. * ssh(1): add a ssh_config PermitRemoteOpen option that allows the client to restrict the destination when RemoteForward is used with SOCKS. * ssh(1): for FIDO keys, if a signature operation fails with a "incorrect PIN" reason and no PIN was initially requested from the user, then request a PIN and retry the operation. This supports some biometric devices that fall back to requiring PIN when reading of the biometric failed, and devices that require PINs for all hosted credentials. * sshd(8): implement client address-based rate-limiting via new sshd_config(5) PerSourceMaxStartups and PerSourceNetBlockSize directives that provide more fine-grained control on a per-origin address basis than the global MaxStartups limit. OpenSSH 8.4/8.4p1 (2020-09-27) New features ------------ * ssh(1), ssh-keygen(1): support for FIDO keys that require a PIN for each use. These keys may be generated using ssh-keygen using a new "verify-required" option. When a PIN-required key is used, the user will be prompted for a PIN to complete the signature operation. * sshd(8): authorized_keys now supports a new "verify-required" option to require FIDO signatures assert that the token verified that the user was present before making the signature. The FIDO protocol supports multiple methods for user-verification, but currently OpenSSH only supports PIN verification. * sshd(8), ssh-keygen(1): add support for verifying FIDO webauthn signatures. Webauthn is a standard for using FIDO keys in web browsers. These signatures are a slightly different format to plain FIDO signatures and thus require explicit support. * ssh(1): allow some keywords to expand shell-style ${ENV} environment variables. The supported keywords are CertificateFile, ControlPath, IdentityAgent and IdentityFile, plus LocalForward and RemoteForward when used for Unix domain socket paths. bz#3140 * ssh(1), ssh-agent(1): allow some additional control over the use of ssh-askpass via a new $SSH_ASKPASS_REQUIRE environment variable, including forcibly enabling and disabling its use. bz#69 * ssh(1): allow ssh_config(5)'s AddKeysToAgent keyword accept a time limit for keys in addition to its current flag options. Time- limited keys will automatically be removed from ssh-agent after their expiry time has passed. * scp(1), sftp(1): allow the -A flag to explicitly enable agent forwarding in scp and sftp. The default remains to not forward an agent, even when ssh_config enables it. * ssh(1): add a '%k' TOKEN that expands to the effective HostKey of the destination. This allows, e.g., keeping host keys in individual files using "UserKnownHostsFile ~/.ssh/known_hosts.d/%k". bz#1654 * ssh(1): add %-TOKEN, environment variable and tilde expansion to the UserKnownHostsFile directive, allowing the path to be completed by the configuration (e.g. bz#1654) * ssh-keygen(1): allow "ssh-add -d -" to read keys to be deleted from stdin. bz#3180 * sshd(8): improve logging for MaxStartups connection throttling. sshd will now log when it starts and stops throttling and periodically while in this state. bz#3055 OpenSSH 8.3/8.3p1 (2020-05-27) New Features ------------ * sshd(8): make IgnoreRhosts a tri-state option: "yes" to ignore rhosts/shosts, "no" allow rhosts/shosts or (new) "shosts-only" to allow .shosts files but not .rhosts. * sshd(8): allow the IgnoreRhosts directive to appear anywhere in a sshd_config, not just before any Match blocks; bz3148 * ssh(1): add %TOKEN percent expansion for the LocalFoward and RemoteForward keywords when used for Unix domain socket forwarding. bz#3014 * all: allow loading public keys from the unencrypted envelope of a private key file if no corresponding public key file is present. * ssh(1), sshd(8): prefer to use chacha20 from libcrypto where possible instead of the (slower) portable C implementation included in OpenSSH. * ssh-keygen(1): add ability to dump the contents of a binary key revocation list via "ssh-keygen -lQf /path" bz#3132 OpenSSH 8.2 FEATURE: Add FIDO/U2F Support OpenSSH 8.1, released in October 2019 ssh, sshd, ssh-agent: add protection for private keys at rest in RAM against speculation and memory side-channel attacks like Spectre, Meltdown and Rambleed. OpenSSH 8.0, released in April 2019 SECURITY: CVE-2019-6111 related to scp tool and protocol allowing to overwrite arbitrary files in the scp client target directory OpenSSH 7.9, released in October 2018 allow key revocation lists (KRLs) to revoke keys specified by SHA256 hash OpenSSH 7.8, released in August 2018 Incompatible changes: ssh-keygen write OpenSSH format private keys by default instead of using OpenSSL's PEM format. OpenSSH 7.7, released in February 2018 FEATURE: Add "expiry-time" option in sshd for authorized_keys files to allow for expiring keys. OpenSSH 7.6, released in October 2017 FEATURE: Add RemoteCommand option FEATURE: Add SyslogFacility option to ssh matching the equivalent option in sshd FEATURE: ssh client reverse dynamic forwarding -R OpenSSH 7.5, released in March 2017 BUGFIX: This is a mainly a bugfix release. OpenSSH 7.4, released Template:Release date and age sshd(8): Add a sshd_config DisableForwarding option - Centos 7.9 (7.9.2009) OpenSSH 7.3, released August 01, 2016 FEATURE: Adds ProxyJump option (-J) FEATURE: Add an Include directive for ssh_config(5) files OpenSSH 7.1: August 20, 2015 This is a bugfix release. OpenSSH 7.0: August 11, 2015 The focus of this release is primarily to deprecate weak, legacy and unsafe cryptography. OpenSSH 6.9: July 1, 2015 BUGFIX: This is primarily a bugfix release. OpenSSH 6.8: March 18, 2015 Added new hostkeys@openssh.com extension to facilitate public key discovery and rotation for trusted hosts (for transition from DSA to Ed25519 public host keys) AuthenticationMethods=publickey,publickey to require that users authenticate using two different public keys OpenSSH 6.7: October 6, 2014 The default set of ciphers and MACs has been altered to remove unsafe algorithms. In particular, CBC ciphers and arcfour* are disabled by default. Compile-time option to not depend on OpenSSL Add support for Unix domain socket forwarding OpenSSH 6.6: March 16, 2014 This is primarily a bugfix release. OpenSSH 6.5: January 30, 2014 Added new ssh-ed25519 and ssh-ed25519-cert-v01@openssh.com public key types (available since 2005 but more popular since some suspicious that NSA had chosen values that gave them an advantage in factoring public-keys) Added new chacha20-poly1305@openssh.com transport cipher Added curve25519-sha256@libssh.org key exchange FEATURE: ssh, added Match keyword for ssh_config that allows conditional configuration to be applied FEATURE: client-side hostname canonicalisation: CanonicalDomains, CanonicalizeFallbackLocal, CanonicalizeHostname, CanonicalizeMaxDots and CanonicalizePermittedCNAMEs. Add a new private key format that uses a bcrypt KDF OpenSSH 6.4: November 8, 2013 This release fixes a security bug with AES-GCM OpenSSH 6.3: September 13, 2013 This release is predominantly a bugfix release OpenSSH 6.2: March 22, 2013 Add a GCM-mode for the AES cipher, similar to RFC 5647 Added support for encrypt-then-mac MAC modes Added support for multiple required authentication methods Added support for Key Revocation Lists (KRL) OpenSSH 6.1: August 29, 2012 This is primarily a bugfix release. Enables pre-auth sandboxing by default Finds ECDSA keys in ssh-keyscan and SSHFP DNS records by default now OpenSSH 6.0: April 22, 2012 This is primarily a bugfix release. OpenSSH 5.9: September 6, 2011 Introduce sandboxing of the pre-auth privilege separated child OpenSSH 5.8: February 4, 2011 OpenSSH 5.7: January 24, 2011 Added support for elliptic curve cryptography for key exchange as well as host/user keys, per RFC 5656 OpenSSH 5.6: August 23, 2010 Added a ControlPersistoption to ssh_config OpenSSH 5.5: April 16, 2010 OpenSSH 5.4: March 8, 2010 Disabled SSH protocol 1 default support. Clients and servers must now explicitly enable it. Added PKCS11 authentication support for ssh(1) (-I pkcs11) Added Certificate based authentication Added "Netcat mode" for ssh(1) (-W host:port). Similar to "-L tunnel", but forwards instead stdin and stdout. This allows, for example, using ssh(1) itself as a ssh(1) ProxyCommand to route connections via intermediate servers, without the need for nc(1) on the server machine. Added the ability to revoke public keys in sshd(8) and ssh(1). While it was already possible to remove the keys from authorised lists, revoked keys will now trigger a warning if used. OpenSSH 5.3: October 1, 2009 OpenSSH 5.2: February 23, 2009 OpenSSH 5.1: July 21, 2008 Added a MaxSessions option to sshd_config OpenSSH 5.0: April 3, 2008 OpenSSH 4.9: March 30, 2008 Added chroot support for sshd(8) Create an internal SFTP server for easier use of the chroot functionality OpenSSH 4.7: September 4, 2007 - Ubuntu 8.04 OpenSSH 4.6: March 9, 2007 OpenSSH 4.5: November 7, 2006 OpenSSH 4.4: September 27, 2006 OpenSSH 4.3: February 1, 2006 Added OSI layer 2/3 tun-based VPN (-w option on ssh(1)) OpenSSH 4.2: September 1, 2005 OpenSSH 4.1: May 26, 2005 OpenSSH 4.0: March 9, 2005 OpenSSH 3.9: August 18, 2004 Implement session multiplexing. ControlMaster option Added a MaxAuthTries option to sshd, allowing control over the maximum number of authentication attempts permitted per connection Added IdentitiesOnly option to ssh which specifies that it should use keys specified in ssh_config, rather than any keys in ssh-agent Re-introduce support for PAM password authentication OpenSSH 3.8: February 24, 2004 OpenSSH 3.7.1: September 16, 2003 OpenSSH 3.7: September 16, 2003 rhosts authentication has been removed in ssh(1) and sshd(8). OpenSSH 3.6.1: April 1, 2003 OpenSSH 3.6: March 31, 2003 OpenSSH 3.5: October 14, 2002 OpenSSH 3.4: June 26, 2002 OpenSSH 3.0: Improved Kerberos support in protocol v1 (KerbIV and KerbV) OpenSSH 2.9.9: OpenSSH 2.5.1p1: February 19, 2001 SkeyAuthentication absoleted, use ChallengeResponseAuthentication instead. OpenSSH 1.2.2p1: March 5, 2000