iptables fowarding правила

Если вы хотите скрыть все выходные данные от выполняемых команд (как выходные данные, так и ошибки), но по-прежнему иметь возможность печатать сообщения самостоятельно, то подход Хауке Лагинга является абсолютно правильным способом для этого.

Позволяет сохранить ссылку на stdout (он же дескриптор файла 1) и stderr (он же дескриптор файла 2), перенаправить их на/dev/null, но использовать их при необходимости отображения сообщения. Я просто хочу добавить кучу комментариев, которые точно объясняют, что он делает.

exec 3>&1 # Open file descriptor 3, writing to wherever stdout currently writes
exec 4>&2 # Open file descriptor 4, writing to wherever stderr currently writes

exec 1>/dev/null # Redirect stdout to /dev/null, leaving fd 3 alone
exec 2>/dev/null # Redirect stderr to /dev/null, leaving fd 4 alone

# Programs won't show output by default; they write to fd 1 which is now /dev/null.
# This is because programs inherit file descriptors from the shell by default.
echo foo

# You can choose to show messages by having them write to fd 3 (old stdout) instead.
# This works by saying that echo's fd 1 (stdout) is the shell's fd 3.
echo bar >&3

# And when you're done you can reset things to how they were to start with
exec 1>&3 # Point stdout to where fd 3 currently points (the original stdout)
exec 2>&4 # Point stderr to where fd 4 currently points (the original stderr)

exec 3>&- # Close fd 3 (it now points to the same spot as fd 1, so we don't need it)
exec 4>&- # Close fd 4 (it now points to the same spot as fd 1, so we don't need it)

Если вы собираетесь использовать это в сценарии любого размера, и вы часто хотите печатать обновления состояния о том, как идут дела, вы, вероятно, хотите создать вспомогательные функции, которые делают эхо «$ @» > & 3 и echo «$ @» > & 4 для печати сообщений в исходном stdout и stderr, так что вам не нужно переходить ссылки на & 3 и & 4 по всему сценарию.

И это bash-hackers.org руководство по перенаправлению является довольно хорошим визуальным изображением того, как умеренно сложные перенаправления, подобные этим, на самом деле работают.

У меня была та же самая проблема, и для меня решением было установить UsePAM в нет . Смотрите, даже если для параметра PasswordAuthentication установлено значение no , вы все равно получите значение keyboard-interactive , и в моем случае моя локальная ssh-программа по какой-то причине продолжает выполнять это по умолчанию.

Дополнительный фон, чтобы помочь любому в той же ситуации: я подключаюсь с хоста под управлением Dropbear к хосту под управлением OpenSSH. Если для параметров PasswordAuthentication и UsePAM на удаленном компьютере установлено значение no , то при вводе ssh user @ server будет получено следующее сообщение:

ssh: Connection to user@server:22 exited: Disconnect received

Предоставление файла удостоверения с параметром -i все работает как ожидалось.

Здесь может быть немного больше информации.

Выполнение iptables-save приведет к выгрузке текущего набора iptables ruleset в stdout , показывая, в свою очередь, команды, используемые для создания набора правил брандмауэра, за вычетом команды iptables