экран -D -R ... Если необходимо отсоединиться и выйти из системы удаленно - для чего здесь нужен "удаленный выход"?

Вы можете сделать свой сценарий оболочки следующим образом:---

#!/bin/bash
read -rp "Input the path..." dir2
dir1=$pwd
#First Check the existence of directory
if [[ -d "$dir2" ]]
    then
    #If it is a valid directory then count the number of files in each directory
    count1=$(find $dir1 -type f | wc -l)
    count2=$(find $dir2 -type f | wc -l)
    #Compare the number of files in the two directories
    if [ $count1 -gt $count2 ]
         then
         echo "Current Directory has more files"
    else if [ $count1 -eq $count2 ]
         then
         echo "Both Directories have same number of files"
    else 
         echo "Input Directory has greater number of files"
    fi
    fi
else
    #If not a valid directory
    echo "Invalid Directory"
fi
0
25.10.2019, 09:31
1 ответ

Когда вы запускаете screenна сервере, вы на самом деле одновременно имеете два терминальных сеанса :, первый из которых вы подключились по SSH, а второй, «локальный», которым управляет screenкоманда. Если первый сеанс завершается по какой-либо причине без надлежащего выхода из screen, эти два сеанса автоматически отделяются друг от друга, и когда вы устанавливаете новый сеанс SSH, screenпозволяет повторно подключиться к существующему второму сеансу.

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

Таким образом, если брандмауэр отключает SSH-соединение, а затем вы вводите хотя бы один символ в SSH-соединении, брандмауэр отправит обратно клиенту SSH сообщение TCP Reset, и вы увидите, что соединение было прервано.Но сторона SSH-сервера не обязательно знает об этом :, если сервер не пытался ничего вам отправить, он может все еще сидеть там, ожидая каких-либо входных данных от вас, на TCP-соединении, которое -, насколько известно серверу, -все еще подключен, но бездействует.

В этом конкретном случае вам понадобится опция -Dв screen -DR, чтобы отключить сеанс screenот старого сеанса SSH, даже если screenсчитает, что он все еще подключен.

В качестве побочного эффекта сервер попытается отправить на выходе (сообщение об «отключении» от screenи новое приглашение оболочки )в начальном отключенном -сеансе SSH., брандмауэр отправит обратно сброс TCP, и поэтому sshdна стороне сервера, наконец, получит информацию о том, что старое соединение SSH было прервано на сетевом уровне, и очистит его.

Но если причиной истечения времени ожидания вашего сеанса SSH является что-то на сервере, вызывающее прекращение вашего первого сеанса SSH, например, администратор сервера установил для ClientAliveCountMaxзначение 0 в sshd_configи ClientAliveIntervalдля некоторого не -нулевое значение в качестве хака, чтобы получить своего рода -тайм-аут бездействия из sshd, тогда ваш старый сеанс SSH будет полностью отключен, а сеанс screenуже будет ждать вас в уже -отделенное государство. В таком случае для переподключения к нему будет достаточно просто screen -R... но дополнительное указание опции -Dв этом случае не помешает.


Между прочим, злоупотребление настройками ClientAliveIntervalи ClientAliveCountMaxв sshd_configтаким образом — довольно ненадежный способ установить тайм-аут бездействия пользователя, поскольку клиентская сторона может обойти это, не зная, что они делают это . Это связано с тем, что ClientAliveIntervalпредназначен для мониторинга активности на уровне соединения SSH, а не фактической активности пользователя.

Если пользователь клиента SSH испытывает проблемы с тайм-аутом сети,они могут установить ServerAliveIntervalв своем~/.ssh/config(или эквивалентном параметре на клиенте OpenSSH, отличном от -). Если для клиента ServerAliveIntervalустановлено значение меньше, чем тайм-аут бездействия соединения брандмауэра, это приведет к тому, что клиент SSH автоматически отправит зашифрованный SSH-сообщение «Вы все еще здесь?» пакет при бездействии, и sshdна сервере ответит на него, сбрасывая таймеры бездействия на брандмауэре.

Но установка на стороне клиента -ServerAliveIntervalболее короткого значения тайм-аута также приведет к тому, что сервер никогда не достигнет тайм-аута ClientAliveIntervalдо тех пор, пока SSH-соединение действительно работает, отменяя предполагаемый «тайм-аут бездействия пользователя»..

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

2
28.01.2020, 02:29

Теги

Похожие вопросы