Как закрыть этот SSH туннель?

Question

Как закрыть этот SSH туннель?

61

Я открыл туннель ssh, как описано в этом сообщении: Zend_Db: Как подключиться к базе данных MySQL через туннель SSH?

Но теперь я не знаю, что я на самом деле делал. Эта команда влияет на что-либо на сервере? И как мне закрыть этот туннель, потому что теперь я не могу правильно использовать свой локальный mysql.

Я использую OSX Lion, а сервер работает на Ubuntu 11.10.

Jacob 25 фев. 2012, в 18:55

Источник

Теги:

mysql

ubuntu

macos

ssh

3 ответа

36

Это убьет все сеансы ssh, которые вы открыли с терминала.

sudo killall ssh

thenetimp 25 фев. 2012, в 19:58

0

«Не найдено ни одного подходящего процесса», - говорит он.
Jacob 25 фев. 2012, в 20:43
0

тогда это закрыто.
thenetimp 25 фев. 2012, в 20:44
0

Кажется, что это так. Mysql тоже хорошо работал, но потом Apache начал жаловаться. Я сделал перезагрузку и все работает как положено. Проблема решена, я думаю :)
Jacob 25 фев. 2012, в 20:55
0

круто, можешь дать мне галочку "большой оле", чтобы я мог получить немного повторений? ;-)
thenetimp 25 фев. 2012, в 21:23
5

Ну, вы не хотите делать это, если это среда prod ... вы выгнаете всех других администраторов
texasbruce 14 янв. 2015, в 20:21
6

Запуск killall ssh - довольно безрассудная команда. Я советую поискать в вашем списке процессов (например, ps aux | grep ssh как предложено выше в @simont), чтобы найти конкретный идентификатор процесса вашего туннельного процесса ssh. Тогда вы можете убить PID, что конкретно.
Ben 25 май 2016, в 16:18
0

Есть большая вероятность, что вы не захотите, чтобы их всех убили.
wobbily_col 11 янв. 2018, в 11:58
0

ты не веселый ;-)
thenetimp 11 янв. 2018, в 15:16

Показать ещё 6 комментариев

11

Примечание: добавление в качестве ответа, поскольку комментарии не поддерживают блоки кода.

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

ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
... do yer stuff... launch mysql workbench whatever
echo "killing ssh tunnel $pid"
kill $pid

Или еще лучше, просто создайте это как оболочку script:

# backend-tunnel <your cmd line, possibly 'bash'>
ssh -N -L1234:other:1234 server &
pid=$!
echo "waiting a few seconds to establish tunnel..."
sleep 5
"$@"
echo "killing ssh tunnel $pid"
kill $pid

backend-tunnel mysql-workbench

backend-tunnel bash

aaron 12 апр. 2013, в 19:54

11

Использование -f позволяет сеансу ssh продолжаться, даже когда сеанс терминала закрыт, в отличие от перехода в фоновый режим. Схватив pid с помощью ps aux | grep ssh | grep <LOCAL-PORT> довольно тривиален.
simont 23 апр. 2013, в 03:56
0

Это именно то, что я искал.
respectTheCode 16 янв. 2015, в 16:16
1

@simont, использующий явный pid, возвращаемый из фонового задания, безопаснее, независимо от того, как вы его используете. если у вас запущено более одного процесса ssh, у вас будет плохое время
aaron 17 янв. 2015, в 19:31
0

Использование -f также имеет то преимущество, что при необходимости запрашивает у локального пользователя пароль для входа. Если вы используете & , этот запрос не будет виден пользователю, если он не выведет процесс на передний план (например, с помощью fg ).
Bdoserror 12 май 2015, в 22:01
0

См. Также Открытие и закрытие туннеля SSH в сценарии оболочки.
here 08 июль 2015, в 22:35
0

@simont ps aux | grep ssh | grep <port> был именно тем , что я искал. Я пробовал так много других способов, которые никогда не работали. Оказывается, самый простой способ может быть лучшим способом :)
Pierce 15 авг. 2015, в 23:36
3

в первый раз, когда ваш <LOCAL-PORT> появляется в pid процесса, который также содержит текст 'ssh' (например, другой процесс ssh или sshd или редактирование файла с именем 'ssh'), вы поймете, что это подход, хотя и удобен в простых сценариях, не является пуленепробиваемым
aaron 17 авг. 2015, в 15:52

Показать ещё 5 комментариев

Ещё вопросы

«Не найдено ни одного подходящего процесса», - говорит он.
Кажется, что это так. Mysql тоже хорошо работал, но потом Apache начал жаловаться. Я сделал перезагрузку и все работает как положено. Проблема решена, я думаю :)
круто, можешь дать мне галочку "большой оле", чтобы я мог получить немного повторений? ;-)
Ну, вы не хотите делать это, если это среда prod ... вы выгнаете всех других администраторов
Запуск killall ssh - довольно безрассудная команда. Я советую поискать в вашем списке процессов (например, ps aux | grep ssh как предложено выше в @simont), чтобы найти конкретный идентификатор процесса вашего туннельного процесса ssh. Тогда вы можете убить PID, что конкретно.
Есть большая вероятность, что вы не захотите, чтобы их всех убили.
Использование -f позволяет сеансу ssh продолжаться, даже когда сеанс терминала закрыт, в отличие от перехода в фоновый режим. Схватив pid с помощью ps aux | grep ssh | grep <LOCAL-PORT> довольно тривиален.
@simont, использующий явный pid, возвращаемый из фонового задания, безопаснее, независимо от того, как вы его используете. если у вас запущено более одного процесса ssh, у вас будет плохое время
Использование -f также имеет то преимущество, что при необходимости запрашивает у локального пользователя пароль для входа. Если вы используете & , этот запрос не будет виден пользователю, если он не выведет процесс на передний план (например, с помощью fg ).
См. Также Открытие и закрытие туннеля SSH в сценарии оболочки.
@simont ps aux | grep ssh | grep <port> был именно тем , что я искал. Я пробовал так много других способов, которые никогда не работали. Оказывается, самый простой способ может быть лучшим способом :)
в первый раз, когда ваш <LOCAL-PORT> появляется в pid процесса, который также содержит текст 'ssh' (например, другой процесс ssh или sshd или редактирование файла с именем 'ssh'), вы поймете, что это подход, хотя и удобен в простых сценариях, не является пуленепробиваемым

simont · Accepted Answer · 2012-03-02T13-23-00.000Z

Предполагая, что вы выполнили эту команду: ssh -f [email protected] -L 3306:mysql-server.com:3306 -N, как описано в сообщении, которое вы связали.

Поломка команды:

ssh: это довольно понятно. Вызывает ssh.
-f: (На странице man ssh)

Запрашивает ssh для перехода к фону непосредственно перед выполнением команды. Это полезно, если ssh будет запрашивать пароли или фразы, но пользователь хочет это в фоновом режиме.

По существу, отправьте ssh в фоновый режим, как только вы ввели какие-либо пароли, чтобы установить соединение; он возвращает запрос оболочки обратно в localhost, а не записывает вас в remote-host.
[email protected]: удаленный сервер, на который вы хотите войти.
-L 3306:mysql-server.com:3306: Это интересный бит. -L (со страницы man ssh):

[bind_address:] порт: хост: HostPort Указывает, что данный порт на локальном (клиентском) хосте должен быть перенаправляется на данный хост и порт на удаленной стороне.

Итак -L 3306:mysql-server.com:3306 связывает локальный порт 3306 с удаленным портом 3306 на хосте mysql-server.com.

При подключении к локальному порту 3306 соединение пересылается по защищенному каналу на mysql-server.com. Затем удаленный хост mysql-server.com подключается к mysql-server.com на порту 3306.
-N: не выполнять команду. Это полезно для "просто пересылки портов" (цитирование справочной страницы).

Эта команда влияет на что-либо на сервере?

Да, он устанавливает соединение между localhost и mysql-server.com на порту 3306.

И как мне закрыть этот туннель...

Если вы использовали -f, вы заметите, что процесс ssh, который вы открыли, возглавляет фон. Более удобный способ его закрытия - запустить ps aux | grep 3306, найти pid ssh -f ... -L 3306:mysql-server.com:3306 -N и kill <pid>. (Или, может быть, kill -9 <pid>; я забываю, если работает только kill). У этого есть прекрасная возможность не убить все ваши другие ssh соединения; если у вас есть несколько, восстановление их может быть небольшой... болью.

... потому что теперь я не могу правильно использовать свой локальный mysql.

Это связано с тем, что вы эффективно "захватили" локальный mysql процесс и перенаправили любой трафик, который пытается подключиться к нему, и удалите его с удаленного процесса mysql. Более приятным решением будет не использовать локальный порт 3306 в переадресации портов. Используйте что-то, что не используется, например 33060. (Более высокие числа, как правило, менее используются, довольно часто для переадресации такой комбинации: "2525- > 25", "8080- > 80", "33060- > 3306" или похоже, немного запоминает).

Итак, если вы использовали ssh -f [email protected] -L 33060:mysql-server.com:3306 -N, тогда вы указывали бы свою функцию Zend connect-to-mysql на localhost на порт 33060, который подключился бы к mysql-server.com на порту 3306. Очевидно, вы все равно можете подключиться к localhost на порту 3306, так что вы все равно можете использовать локальный сервер mysql.

Лучшее объяснение, которое я прочитал за последнее время. Это очень полезно при доступе к удаленной базе данных из локально установленных сред, таких как, например, R. Хорошо работает с аутентификацией с открытым / закрытым ключом. Не с паролями, потому что я не нашел способ передать пароли.
Принятие этого ответа как лучшего из-за подробного объяснения.
Это отличный ответ. Очень тщательно!
Хороший ответ! Кстати, -9 не нужен для kill , учитывая, что процесс все еще работает нормально ;-)