LINUX.ORG.RU

История изменений

Исправление DRVTiny, (текущая версия) :

1) Команды, передаваемые ssh'у, лучше засунуть в «подвал» скрипта (после exit), обособить сверху и снизу строками (я делаю что-то вроде 

== include.this.shit ->
первой строкой и 
== <- include.this.shit
последней. Можно и просто <peaceOfCode>CODE</peaceOfCode>). Вытаскивать содержимое sed'ом, обрезая строки-терминаторы - и передавать ssh через «$(sed \»$0\")", например. Экранирование там крайне несимпатично и вообще этот кусок кода как ни пришей кобыле хвост болтается

2) Если внутри двойных кавычек ничего не expand'иться, то и не нужно их использовать - для этих случаев есть одинарные кавычки

3) Для конструкции [ test ] в BASH есть своя реализация с гораздо более широкими возможностями: [[ test ]]

4) Очень много хардкода: одно и то же название каталога в куче разных мест, все пути прибиты гвоздями. При этом весь этот хардкод вообще хорошо бы принимать параметрами скрипта: getopts вам в руки

5) А что если выбранный вами port на самом деле уже кем-то занят? Можно конечно смотреть по fail'у ssh, но тогда сам fail разбирать нужно. Не легче ли проверять записью в /dev/tcp/host/port? Ну или lsof/netstat

6) Насчёт логирования здесь правильно заметили: у вас мало того, что тупо echo, так ещё и не в STDERR

C .lock логика мутная немного... Уж если что-то подобное нужно сделать - сохраняйте туда хотя бы pid процесса ssh -L

Кстати, а что оно делает? 

ssh $core \
  -Nf \
  -L $port:localhost:$port \
  -R $port:localhost:22 \
  -o ExitOnForwardFailure=yes
-L перенаправит через туннель весь локальный tcp-трафик на порт $port на машину $core, порт $port (зачем?)

-R перенаправит через другой (?) туннель весь трафик на машине $core, который шёл на tcp-порт $port, на вашу локальную машину (где запускается скрипт), порт 22. В итоге по идее если сделать коннект на локальную машину, порт $port, то этот коннект уйдёт на $core и через другой туннель вернётся снова на локальную машину, на sshd-сервер.

Ничего не понимаю, это зачем так?

Исправление DRVTiny, :

1) Команды, передаваемые ssh'у, лучше засунуть в «подвал» скрипта (после exit), обособить сверху и снизу строками (я делаю что-то вроде 

== include.this.shit ->
первой строкой и 
== <- include.this.shit
последней. Можно и просто <peaceOfCode>CODE</peaceOfCode>). Вытаскивать содержимое sed'ом, обрезая терминатора - и передавать ssh через «$(sed )», например. Экранирование там крайне несимпатично и вообще этот кусок кода как ни пришей кобыле хвост болтается

2) Если внутри двойных кавычек ничего не expand'иться, то и не нужно их использовать - для этих случаев есть одинарные кавычки

3) Для конструкции [ test ] в BASH есть своя реализация с гораздо более широкими возможностями: [[ test ]]

4) Очень много хардкода: одно и то же название каталога в куче разных мест, все пути прибиты гвоздями. При этом весь этот хардкод вообще хорошо бы принимать параметрами скрипта: getopts вам в руки

5) А что если выбранный вами port на самом деле уже кем-то занят? Можно конечно смотреть по fail'у ssh, но тогда сам fail разбирать нужно. Не легче ли проверять записью в /dev/tcp/host/port? Ну или lsof/netstat

6) Насчёт логирования здесь правильно заметили: у вас мало того, что тупо echo, так ещё и не в STDERR

C .lock логика мутная немного... Уж если что-то подобное нужно сделать - сохраняйте туда хотя бы pid процесса ssh -L

Кстати, а что оно делает? 

ssh $core \
  -Nf \
  -L $port:localhost:$port \
  -R $port:localhost:22 \
  -o ExitOnForwardFailure=yes
-L перенаправит через туннель весь локальный tcp-трафик на порт $port на машину $core, порт $port (зачем?)

-R перенаправит через другой (?) туннель весь трафик на машине $core, который шёл на tcp-порт $port, на вашу локальную машину (где запускается скрипт), порт 22. В итоге по идее если сделать коннект на локальную машину, порт $port, то этот коннект уйдёт на $core и через другой туннель вернётся снова на локальную машину, на sshd-сервер.

Ничего не понимаю, это зачем так?

Исходная версия DRVTiny, :

1) Команды, передаваемые ssh'у, лучше засунуть в «подвал» скрипта (после exit), обособить сверху и снизу строками (я делаю что-то вроде == include.this.shit -> первой строкой и == <- include.this.shit последней). Экранирование там крайне несимпатично.

2) Если внутри двойных кавычек ничего не expand'иться, то и не нужно их использовать - для этих случаев есть одинарные кавычки

3) Для конструкции [ test ] в BASH есть своя реализация с гораздо более широкими возможностями: [[ test ]]

4) Очень много хардкода: одно и то же название каталога в куче разных мест, все пути прибиты гвоздями. При этом весь этот хардкод вообще хорошо бы принимать параметрами скрипта: getopts вам в руки

5) А что если выбранный вами port на самом деле уже кем-то занят? Можно конечно смотреть по fail'у ssh, но тогда сам fail разбирать нужно. Не легче ли проверять записью в /dev/tcp/host/port? Ну или lsof/netstat

6) Насчёт логирования здесь правильно заметили: у вас мало того, что тупо echo, так ещё и не в STDERR

C .lock логика мутная немного... Уж если что-то подобное нужно сделать - сохраняйте туда хотя бы pid процесса ssh -L

Кстати, а что оно делает? 

ssh $core \
  -Nf \
  -L $port:localhost:$port \
  -R $port:localhost:22 \
  -o ExitOnForwardFailure=yes
-L перенаправит через туннель весь локальный tcp-трафик на порт $port на машину $core, порт $port (зачем?)

-R перенаправит через другой (?) туннель весь трафик на машине $core, который шёл на tcp-порт $port, на вашу локальную машину (где запускается скрипт), порт 22. В итоге по идее если сделать коннект на локальную машину, порт $port, то этот коннект уйдёт на $core и через другой туннель вернётся снова на локальную машину, на sshd-сервер.

Ничего не понимаю, это зачем так?