• Serveurs
  • Screen terminé lors de la deconnexion du terminal SSH

Banip

Pour tout dire j'ai testé d'abord sur un VPS, aussi sous debian 9 et installé avec bonobox et là j'ai bien le comportement "normal" :
- lorsque la commande vnc est lancé dans la session ssh sans screen, elle est arrêté à la déconnexion du ssh
- lorsque la commande vnc est lancé dans un screen détaché du terminal alors elle reste active aussi longtemps que désiré, elle ne se coupe pas toute seule.

J'ai comparé la configuration de vnc sur les 2 serveurs et c'est la même.

Et sur mon serveur principal dés que je me déconnecte de mon terminal ssh, la commande vnc se coupe aussi, screen ou pas, que je me déconnecte du ssh en 30s ou 15min, même résultat...

Erusaris
Voilà le log :

28/02/18 19:12:06 rfbProcessClientNormalMessage: ignoring unknown encoding 22
28/02/18 19:12:06 rfbProcessClientNormalMessage: ignoring unknown encoding 21
28/02/18 19:12:06 rfbProcessClientNormalMessage: ignoring unknown encoding 16
28/02/18 19:12:06 rfbProcessClientNormalMessage: ignoring unknown encoding -314
28/02/18 19:12:06 Enabling full-color cursor updates for client 86.198.8.47
28/02/18 19:12:06 rfbProcessClientNormalMessage: ignoring unknown encoding -223
28/02/18 19:12:06 Pixel format for client 86.198.8.47:
28/02/18 19:12:06   32 bpp, depth 24, little endian
28/02/18 19:12:06   true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0
28/02/18 19:12:06   no translation needed

    Je viens d’essayer sur mon local et après ta dernière ligne j'ai ce type d'entrée :

    01/03/18 02:41:02 Got connection from client 192.168.1.10
    01/03/18 02:41:03   (other clients 192.168.1.10)
    01/03/18 02:41:03 Using protocol version 3.8
    01/03/18 02:41:03 Full-control authentication passed by 192.168.1.10

    Visiblement ce serais sur un vps l'install? Le port et bien ouvert ?

    Edit : Derrière l'ip du log c'est un synology chez orange qui répond. Tu es sur de ne pas t'être trompé de console ssh ?

    Garrus
    Est ce le même utilisateur qui lance les commandes sur les deux serveurs ? Ou sur le serveur qui fonctionne tu as lancé en root ?
    Une piste, dans le fichier /etc/systemd/logind.conf de tes serveurs, peux tu voir la ligne suivante ?

    #KillUserProcesses=no

    Vérifie si elle n'est pas dé-commenté et sur yes sur le serveur ou tu as ton problème 🙂

    Je vais commencer a sécher par contre...

    @Erusaris
    non c’est bien correct, c’est juste l’ip de mon ordi client, qui se trouve bien derrière une box orange, sur laquelle j’ai bien un n’as synology branché

    @Banip
    C’est bien le même utilisateur qui lance la commande, root.
    Quand à la ligne que tu m’as indiqué elle est bien décoché, mais ça m’a donné une idée : peut être qu’il y a une option dans sshd_config qui fout la merde sur le serveur où ça marche pas ?
    Voilà le sshd_config du serveur qui déconne :
    https://paste.mondedie.fr/?8138561460926940#lplwMas3lcviciGmZ11bMjDcmKs5c7CWuvoRXY04w/A=

    Et le ssd_config du serveur qui fonctionne :
    https://paste.mondedie.fr/?33402f1b71809993#oqaZY9/E/AboWAYwP3ZHvy7Gmlz5Rmgx1S5PrZNSoaA=

    Il y a quelques différences dans les config…

      Juste pour comparer tu as essayé avec tmux ?
      (C'est une alternative à screen),

        BarbeRousse
        Oui en cherchant sur internet j'avais vu cette alternative. Je l'ai essayé mais même problème...
        Merci quand même

        Banip
        En ce moment je ne vais pas avoir trop le temps de me penché sur ce problème, je testerais ça un peu plus tard et je reviendrais vous dire ce qu'il en est.

        Merci à tous

          Garrus Ok pas de soucis, hésites pas à me taguer si jamais.

          10 jours plus tard

          Bonjour a tous.
          Me revoilà pour mon problème (j'avais un peu de temps devant moi lol)

          Alors @salorium non je n'ai pas essayé, mais j'ai réussi à solutionner mon problème.

          En fait je me suis rappelé que lorsque j'avais installé mon serveur j'avais eu un petit soucis avec ssh et que la solution que j'avais trouvé à ce moment là c'etait ça :

          systemctl disable ssh.service
          systemctl enable ssh.socket
          

          J'ai donc tenté l'inverse, pour revenir à ma situation de départ :

          systemctl disable ssh.socket
          systemctl enable ssh.service
          

          Et c'est bon... mes screen ne sont plus terminés à la déconnexion de mon terminal.

          C'est donc résolu, merci à tous pour votre aide

            Garrus Si tu pouvais mettre ta réponse en tant que meilleur réponse ? Cela permet de passer ton post en résolu et apporte de la visibilité pour les futures personnes qui passeront par là.

            Au plaisir.

              Répondre…