Почему мой tar через ssh (команда через author_keys) портит архив?

Question

С бэкапа я хочу вытащить дампы tgz рабочего сервера. Обе машины работают под управлением Ubuntu 16.04.

Поэтому резервный сервер подключается через ssh и определенный ssh к производственному серверу.

Файл ~/.ssh/authorized_keys соответствующего пользователя на производственном сервере должен просто разрешать одну команду и накладывать как можно больше ограничений (? Я надеюсь):

command="tar -cz --file - --ignore-command-error --ignore-failed-read /dir/ 2>/dev/null | cat",no-agent-forwarding,no-port-forwarding,no-user-rc,no-X11-forwarding ssh-rsa AABLASHKEY comment

где /dir/ - каталог для резервного копирования, AABLASSHKEY и comment - это, конечно , "реальные" значения.

| В этом случае требуется | cat потому что иначе tar в этой версии Ubuntu («tar (GNU tar) 1.28») не будет говорить с stdout, заданным ssh (PTY). Stderr должен войти в пустоту (2> /dev/null). Редактировать: точка зрения о PTY является заблуждением, см. Ответ @grawity.

На принимающей стороне (сервере backup ) я подхожу так:

ssh -i /path/to/key the-user@production-server > dir.tgz

Однако полученный файл отличается по размеру от архива, если я создаю его на сервере, и не является допустимым архивом (например, gzip: stdin: invalid compressed data--crc error ... gzip: stdin: invalid compressed data--length error). Разница в размере составляет 22 байта.

Если я разрешаю резервному серверу любую команду на производительном сервере, сняв ограничения в authorized_keys она будет работать нормально. В какой момент я скучаю?

Ограничения

• Я действительно хочу использовать tar (не rsync, rrsync или что-то в этом роде).
• Соединение должно быть инициировано резервным сервером
• Рабочий сервер не должен создавать никаких временных файлов

Решение

Как отметил @Grawity в своем ответе (прочитайте его, чтобы устранить некоторые заблуждения), следующая строка в ~.ssh/authorized_keys решает проблему (и работает на Ubuntu 16.04 с указанной версией OpenSSH):

command="tar -cz --file - --ignore-command-error --ignore-failed-read /dir/ 2>/dev/null",restrict ssh-rsa ....

Чтобы команда back-up-server не выдавала предупреждений, подключитесь к:

ssh -o RequestTTY=no -i /path/to/key the-user@production-server > dir.tgz

Answer 1

| В этом случае требуется | cat потому что иначе tar […] не будет говорить с stdout, заданным ssh (PTY).

Нет. Наличие PTY - это точно одна из ваших проблем. TTY слой существует для обработки управляющих символов терминала и не то , что вы хотите на все другие виды данных.

Обычно при запуске ssh в пакетном режиме (т. ssh <host> <cmd>) не выделяется серверная часть PTY; это обеспечит 8-битный чистый канал. Но когда вы не предоставляете команду на клиенте, вам нужно явно добавить опцию -T или RequestTTY client, чтобы отключить запрос TTY,

ssh -T theuser@prod > dir.tgz
ssh -o RequestTTY=no theuser@prod > dir.tgz

или предоставьте фиктивную команду,

ssh theuser@prod foo > dir.tgz

или запретите такие запросы с помощью опции no-pty authorized_keys:

command="tar -czf - /dir/ 2>/dev/null",no-pty,restrict ssh-rsa ABCDEF

(restrict - недавно добавленный псевдоним, который отключает все переадресации сразу, включая те, которые могут быть добавлены в будущем. Доступен начиная с OpenSSH 7.2. На самом деле, он даже включает no-pty , хотя я и перечислил его отдельно для этого ответа.)