Vindicar

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

Я думаю, схема будет такая:
1. При входе на целевую страницу, JS генерирует AJAX запрос с помощью fetch() или XMLHttpRequest, на твой выбор. Форму запроса (GET/POST) и передаваемые данные определяешь ты сам, но их должно быть достаточно для идентификации пользователя. В простейшем случае URL целевой страницы должен быть уникальным для каждого пользователя, и тогда можно будет передать этот уникальный идентификатор.
2. Есть небольшой HTTP-сервер, который принимает эти запросы, записывает их в локальную базу данных и даёт отклик вида "успех/неудача". На чем он написан - неважно, но для простоты можно использовать Flask. Там будет строк 100 от силы. В качестве базы можно использовать sqlite.
3. Есть Python бот, использующий одну из библиотек под телегу, который периодически смотрит в эту базу и проверяет наличие необслуженных запросов. Если таковые находятся, бот их перебирает, определяет для каждого запроса соответствующего пользователя, отправляет файл, и помечает запрос как обслуженный (ну или просто удаляет).


Есть соблазн совместить пункты 2 и 3 в одном процессе, но это может оказаться нетривиально - тебе придётся крутить работу веб-сервера в главном потоке, а работу бота - в дополнительном. Тогда вместо базы данных можно будет использовать очередь (threading.Queue) - главный поток (Flask) кладёт задания в очередь, а поток бота - выбирает и обслуживает.

Плюсы - один Python-скрипт вместо двух, отсутствие промежуточной БД.
Минусы - повышенная сложность скрипта, при внезапной остановке скрипта текущие задания в очереди будут потеряны, труднее вести статистику обслуживания ботом пользователей.
Решай сам, стоит ли оно того.

Есть два подхода. Один основан на лямбдах:

for i in range(2):
    buttonFrame_update=Button(frame,text="Добавить", command= lambda arg=i: update_main_db(arg))

Приём с аргументом лямбды необходим, чтобы сохранить текущее значение i - иначе в момент вызова лямбды она прочитает последнее значение i, а оно будет указывать на последнюю строку.

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

class MyTableRow(Frame):
    def __init__(self, master, *args, **kwargs):
        super().__init__(master, *args, **kwargs)
        self.widgets = []
        for i in range(3):
            widget = Entry(frame)
            widget.pack(side="left")
            self.widgets.append(widget)
        self.update_btn = Button(self, text = "Добавить", command = self.update_clicked)
        self.update_btn.pack(side="right")
        self.delete_btn = Button(self, text = "Удалить", command = self.delete_clicked)
        self.delete_btn.pack(side="right")
  
    def update_clicked(self):
        print(self.widgets[0].get())
    
    def delete_clicked(self):
        print("whatever")


for i in range(2):
    item = MyTableRow(doth, borderwidth=2, relief="groove")
    frames.append(item)
    item.pack(side="top", fill="x")

В ssh есть три варианта проброски портов.
-L lport:remote.host:rport задаёт проброску клиентского порта, т.е.
1. клиент SSH слушает порт lport на своей машине. По умолчанию на всех сетевых интерфейсах, но можно указать желаемый адрес, который будет слушаться, так: bind.address:lport:remote.host:rport
2. когда к этому порту кто-то коннектится, клиент сообщает серверу
3. сервер коннектится на remote.host:rport
4. В дальнейшем данные пробрасываются через этот туннель.

-R rport:local.host:lport работает наоборот
1. сервер SSH слушает порт rport на своей стороне. По умолчанию на всех сетевых интерфейсах, но можно указать желаемый адрес, который будет слушаться, так: bind.address:rport:local.host:lport
2. когда к этому порту кто-то коннектится, сервер уведомляет клиента
3. клиент коннектится на local.host:lport
4. В дальнейшем данные пробрасываются через этот туннель

И последний, самый практичный, но самый трудно контролируемый.
-D lport или -D bind.address:lport
1. клиент слушает порт lport на своей стороне
2. когда к этому порту кто-то коннектится, клиент пробрасывает соединение на ssh сервер
3. ssh сервер отвечает по протоколу прокси SOCKS4/SOCKS5, и выполняет дальнейшие соединения в зависимости от желаний подключившегося приложения.
Т.е. чтобы это работало, нужно чтобы приложение умело работать с SOCKS-прокси.

Не помогает - значит нужно отлаживать. Я не вполне понял, где расположена smb-шара - на том же хосте, что и ssh сервер? Или на другом? Также стоит убедиться, что соединение с ssh сервером устанавливается нормально.
Наконец, стоит выделить под такие туннели отдельного пользователя на сервере, и ограничить его в правах на всё, кроме использования туннеля.

original_list = [0,1,8,3,0,4,5,0,0] #исходный список
new_list = [x for x in original_list if x != 0] #только ненулевые элементы
how_many_zeros =  len(original_list) - len(new_list) #сколько нулей потеряли?
new_list.extend( [0] * how_many_zeros ) # добавляем нужное количество нулей в конец

А не проще ли будет сделать в два прохода.
Прямым проходом делаем так: если 0, то счетчик в ноль, иначе счетчик + 1 и элемент приравниваем счетчику.
Потом то же самое делаем обратным проходом, но изменяем элемент только если он больше счетчика.
Отсюда получаем:

lst=[5, 3, 0, 2, 0, 3, 8, 2, 9, 7, 0, 0, 7, 1, 5, 3]
L = len(lst)
# если в начале списка не 0, то мы сможем задать корректные значения только на обратном ходе
# так что ставим заведомо большее значение счетчика
counter = len(lst) if lst[0] != 0 else 0
for i in range(0, L):
  if lst[i] == 0:
    counter = 0
  else:
    counter += 1
    lst[i] = counter
# обратный ход
counter = lst[-1] - 1 #чтобы не запороть последние элементы
for i in range(L-1, -1, -1):
  if lst[i] == 0:
    counter = 0
  else:
    counter += 1
    lst[i] = min(counter, lst[i])

print(lst)
# [2, 1, 0, 1, 0, 1, 2, 3, 2, 1, 0, 0, 1, 2, 3, 4]

Правда, это даст некорректный результат, если список не содержит нулей. Но это можно обнаружить в ходе первого прохода.

Ты пытаешься сделать рандомный выбор из введённых значений?
А на кой пельмень ты вообще соединяешь args? Если они разделяются пробелом, то так

# команда вызывается как !choice вариант1 вариант_2 "вариант 3"
@commands.command(pass_context=True)
async def choice(self, ctx, *args:str):
  chosen = random.choice(args)

А если прямо нужно через запятую, то лучше так:

# команда вызывается как !choice вариант1, вариант 2, вариант 3
@commands.command(pass_context=True)
# discord.py интерпретирует * как "всю остальную строку засунь в следующий параметр" 
async def choice(self, ctx, *, args:str): 
  choices = [arg.strip() for arg in args.split(',')]
  chosen = random.choice(choices)

Нужно немножко включить голову и почитать про то, как работает SSH и оболочка Unix системы. Гуглинг типа "SSH keep program running" быстро бы вывел тебя на то что нужно.
1. Когда ты подключаешься по SSH, сервер запускает копию bash или sh (или какая там оболочка используется) с правами твоего пользователя.

<br>
sshd<br>
  - bash<br>

При вводе команды в этой оболочке программа ищется в системном PATH, а в нём находится второй питон.

2. Потом, когда ты делаешь activate, ты переходишь в виртуальное окружение. Оно отличается тем, что питон там ищется по умолчанию другой, так как там поменян PATH (и ещё кое что). И происходит этот переход за счёт запуска дочерней командной оболочки.

<br>
sshd<br>
  - bash<br>
      - activate <br>
          - bash<br>

3. Ты запускаешь свой скрипт. Он запускается из под оболочки внутри activate.

<br>
sshd<br>
  - bash<br>
      - activate<br>
          - bash<br>
              - python3 your_script.py<br>

4. Ты закрываешь putty. SSH сервер регистрирует отключение клиента, и посылает дочернему bash сигнал HUP - обычно он интерпретируется как сигнал на завершение. Тот передаёт этот сигнал своему дочернему процессу, и так далее.

<br>
sshd "sshd: эй, bash, завершайся"<br>
  - bash "bash: эй, activate, завершайся. А теперь я сам завершусь."<br>
      - activate "activate: эй, bash, завершайся. А теперь я сам завершусь"<br>
          - bash "bash: эй, python3, завершайся. А теперь я сам завершусь"<br>
              - python3 your_script.py "python3: хорошо, завершаюсь."<br>

В итоге получаем только работающий ssh сервер
sshd
И когда ты переоткрываешь сессию, activate уже перестал существовать, и ты снова попадаешь в обычный bash, где в PATH прописан только второй питон.

Теперь главное: как же это обойти? Нужно сделать так, чтобы python3 проигнорировал сигнал о завершении. Есть несколько способов.
Самый простой - использовать такой синтаксис:
nohup python3 your_script.py &
Амперсанд в конце означает "запусти программу и вернись в оболочку, не дожидаясь когда программа закончит работать". А команда nohup запускает указанную программу с указанными аргументами, но при этом она проигнорирует сигнал HUP, т.е. "эй, завершайся". А потому когда ты закроешь putty, бот должен остаться работать.
Минус - после переподключения ты не будешь видеть вывод бота в консоль. Так что пиши логи!
Чтобы остановить бота, придётся использовать ps чтобы узнать ID его процесса, и kill чтобы этот процесс прибить. Ну или можешь предусмотреть команду выхода в самом боте, которая завершит работу скрипта изнутри. Это удобнее.

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

Третий способ - сделать так, чтобы бот запускался при загрузке, через init.d скрипт или systemd модуль. Но так как у тебя минимальные права, скорее всего это не прокатит.

Не будучи на сервере - нет, насколько я знаю.