Fermer un tunnel SSH

Bonjour,

J’ai un utilisateur est qui est actuellement connecté sur mon serveur.
Coté client, l’utilisateur à fermé ca fenetre putty.

J’arrive à voir la connexion avec cette commande :

root@debian:/var/log# netstat -n --protocol inet | grep ':22'
tcp        0      0 192.168.1.3:22          190.200.40.14:76    ESTABLISHED
tcp        0     52 192.168.1.3:22          192.168.1.2:59048       ESTABLISHED
root@debian:/var/log#

La deuxième m’appartient.

J’aimerais savoir comment la clôturer sans arrêter sshd ?

Pour récupérer le PID du process concerné :

Ensuite tu n’as plus qu’à faire un kill.

Et ptet réinitialiser sshd, non ?

/etc/init.d/ssh restart

[quote=“ricardo”]Et ptet réinitialiser sshd, non ?

/etc/init.d/ssh restart[/quote]

Ça ne coupe pas les connexions actives (pour le vérifier : log toi en SSH sur une machine distante, su/sudo service ssh restart sur ladite machine et tu verras que ta connexion SSH est toujours là :wink:).

a tout hasard , iptables ip - port - drop ?
bon le mieux c est peut être juste un soft qui permettrai de le faire mai j’en connaît pas :\

Cela ne ferait que bloquer l’éventuel trafic, et si la session est déjà fermée côté client, du trafic il n’y en a plus de toute façon.

Redémarrer sshd ne coupe pas les sessions SSH en cours, et heureusement car sinon il serait délicat de faire une mise à jour de ssh à distance.

En plus de netstat, ps avec les différentes options qui affichent le PID et l’utilisateur (-Af, aux…) permet aussi d’identifier le processus à tuer :

UID PID PPID C STIME TTY TIME CMD root 2921 1836 0 10:16 ? 00:00:00 sshd: pascal [priv] pascal 2924 2921 0 10:16 ? 00:00:00 sshd: pascal@pts/1 pascal 2925 2924 0 10:16 pts/1 00:00:00 -bash

Cela ne ferait que bloquer l’éventuel trafic, et si la session est déjà fermée côté client, du trafic il n’y en a plus de toute façon.

Redémarrer sshd ne coupe pas les sessions SSH en cours, et heureusement car sinon il serait délicat de faire une mise à jour de ssh à distance.

En plus de netstat, ps avec les différentes options qui affichent le PID et l’utilisateur (-Af, aux…) permet aussi d’identifier le processus à tuer :

UID PID PPID C STIME TTY TIME CMD root 2921 1836 0 10:16 ? 00:00:00 sshd: pascal [priv] pascal 2924 2921 0 10:16 ? 00:00:00 sshd: pascal@pts/1 pascal 2925 2924 0 10:16 pts/1 00:00:00 -bash [/quote]
et si le processus peux pas être tuer, ce qui m’arrive parfoit, on fait quoi?

kill -9 :mrgreen:

kill -9 :mrgreen:[/quote]
maleureusement sa ne marche pas toujours. et a ce moment ben…

Salut,

Si on veut la vraie commande kill, il faut faire /bin/kill.

-edit-

Je savais bien … man kill

[quote=“man kill”]NOTES

Votre interpréteur de commandes possède probablement une commande kill interne. Vous devriez saisir /bin/kill pour exécuter la commande décrite ici au lieu de la commande interne.

[/quote]

Dans quel cas la commande kill coince?

ricardo@sid-sda8:~$ kill -9 Usage: kill pid ... Send SIGTERM to every process listed. kill signal pid ... Send a signal to every process listed. kill -s signal pid ... Send a signal to every process listed. kill -l List all signal names. kill -L List all signal names in a nice table. kill -l signal Convert between signal numbers and names.
En tant que root : idem.

Faudrait peut-être ajouter le PID du processus à tuer, comme d’habitude. -9 n’en dispense pas (ou alors il pourrait tuer un processus au hasard, ce serait rigolo).

Salut,

Il existe des builtins. Exemple : man bash|less +’/kill ['
Qui peuvent agire différemment (même si derrière, c’est la même fonction système qui est probablement utilisée)

:blush: :blush: :blush:

lsof est un peu plus parlant … :083

[code]# lsof -i -n -P

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME

apache2 2039 www-data 4u IPv6 5901 0t0 TCP *:80 (LISTEN)

sshd 4420 root 3r IPv4 11416 0t0 TCP xxx.xxx.xxx.xxx:22->yyy.yyy.yyy.yyy:56290 (ESTABLISHED)
sshd 4422 3u IPv4 11416 0t0 TCP xxx.xxx.xxx.xxx:22->yyy.yyy.yyy.yyy:56290 (ESTABLISHED)

[/code]
AMHA …

Ça ne répond pas à ma question, dans quel cas un kill -9 ne tue pas le processus de la connexion? Ça ne m’est jamais arrivé. Le seul cas où la connexion subsistait, c’était lors qu’un processus avait été lancé et n’était pas terminé, tuer le bash ou le sshd de la connexion suffisait à ce que le processus soit adopté par init et que la connexion se ferme.

De ce qui est dit ici (attention, je ne veux pas troller sur les UUO), il semble que l’utilisation d’un kill -9 peut être trop radical et laisser des sockets ouverts

hello
un petit exemple ?
chez voila quelque chose qui peux etre reproduit:
les 2 machine sont sous squeez.
Un partage de fichier linux only , serveur <–> clients, avec nfs (plus sur du nom…)

Monter le système en temps que simple utilisateur. Ouvrir un fichier avec ce qui va bien chez moi c est geany. profiter de faire un petit up de fichier (un gros 10 go). puis couper la connections.
le montage reste. de plus geany gèle. le navigateur fichier (gestionnaire de fichier…) gèle , un kill -s 9 pid ou killall nomproc -s 9 , xkill parfois passe mai sa reste rare.

Meilleur solution tuer X , géré ensuite depuis root… mai parfois sa devient ingérable car sa ne marche plus ou mal . sa évite parfois un reboot a la sauvage .

sa compter que parfois le processus reste en mémoire.