SSH : connexion timed out

Support Debian
#1

Bonjour à tous,

Depuis peu, j’ai acheté un QNAP avec une Debian Squeeze Armel (architecture ARM) installée dessus pour me lancer dans l’auto-hébergement.
Mais ça fait 4 ou 5 jours que je ne peux plus me connecter sur le serveur en local avec la commande SSH.
Je me connecte en Wifi avec mon portable (caractéristiques en signature) au réseau local sur la MachinBox.
je fais pourtant la commande habituelle :

ssh -v utilisateur@ip_du_serveur_local -p XXXX root@debian:~# ssh -v utilisateur@192.168.X.XX -p XXXX OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to 192.168.X.XX [192.168.X.XX] port XXXX. debug1: connect to address 192.168.X.XX port XXXX: Connection timed out ssh: connect to host 192.168.X.XX port XXXX: Connection timed out
Je ne vois pas ce que j’aurai pu changer pour avoir ce problème.

Je ne peux plus me connecter en VNC non plus puisque je ne peux plus lancer le serveur VNC avec SSH…
J’avais changé le port 22 pour un autre. Jusque là j’ai pas eu de binz.
La commande Ping ip_du_serveur fonctionne et me renvoie bien des données correctes.
Un telnet Ping ip_du_serveur sur le même port ne fonctionne pas.
Un traceroute ip_du_serveur ne renvoie rien.
J’ai fait un :iptables -F iptables -X sur le client, qui apparemment si j’ai bien compris efface toutes les règles du pare-feu. Mais je ne peux pas le faire sur le serveur, n’ayant plus accès !
J’ai bien redirigé le port 22 client sur le port XXXX de mon serveur sur la page de config de la MachinBox (Neufbox v4).
La commande trouvé sur le net :ps -ae | grep sshd ne renvoie rien. C’est sensé dire apparemment si SSH est activé sur le serveur. Quelqu’un confirme ?
J’ai constaté un truc aussi sur la page de configuration de la Neufbox : le serveur apparaît dans les postes connectés mais il ne reste pas bien longtemps (genre 1mn pas plus) ! Comme s’il avait planté peut-être. Le seul moyen pour moi de l’arrêter, c’est de faire un appui long sur le bouton “Arrêt”, c’est pas très fin je sais…!
Un wakeonlan ne marche pas non plus apparemment, le seul moyen de le faire réapparaître dans la liste des postes connectés, c’est de faire le ping test maison de la MachinBox.
Je suis bien embêté, si j’avais pu reformater (ah les habitudes “windowsiennes” !), je l’aurai fait, j’ai rien, aucune donnée pour le moment sur le serveur. Mais étant sur un serveur NAS QNAP avec une Debian Armel et ayant flashé la mémoire (en ayant quand même fait une sauvegarde du système QNAP proprio) je vois pas trop comment faire…!
La résolution du problème SSH serait bien !

Merci d’avance pour vos réponses.

#2

Salut,

Qu’en pensent-ils ?

forum.qnapclub.fr/

#3

Merci de ta réponse très rapide.

En effet, c’est peut-être plus judicieux de leur demander à eux, mais j’ai un peu peur de la réponse, l’installation d’une Debian Armel dessus bien qu’étant autorisé et supporté, n’est pas le système QNAP proprio.
Je ferai un rapport si j’ai une réponse.
Si quelqu’un a peut-être une autre solution, je suis quand même preneur bien sur !

#4

Re,

C’est à l"aide de google que j’ai trouvé comment installer une debian sur un synology et le problème est le même, à ceci près qu’ils ne sont pas aimables :laughing:

#5

Tot ça est un peu confus.
Visiblement, tu arrives à dialoguer avec la machine, le serveur sshd te répond, c’est déja bien. Combien de temps s’écoule entre ta tentative de connexion et le timeout ?
si tu fais simplement un ssh utilisateur@adresse-machine, que ce passe t il ? (demande de mot de passe ?)

Je n’ai pas compris ton histoire de redirection de port. Si tu es 100% sur ton LAN, je ne comprends pas.

est ce que ton système à une sortie console série (sur usb ou autre) ?

#6

Merci de ta réponse Piratebab.

Désolé si mon message est un peu confus.
Quand je fais la commande SSH, il se passe 1mn (62s mais en comptant avec les doigts !) avant d’avoir le message “connexion timed out”. Je n’ai plus de demande de mot de passe directe comme avant.
Pour les ports, je pensais qu’il fallait les rediriger en LAN aussi. Et c’est quoi une “sortie console série” ?
Je suis un peu noob désolé…!

Le QNAP (TS-119 PII) a 2 ports USB 2.0, 1 USB 3.0 et un port SATA.

#7

habituellement, on redirige les ports sur une box quand on veut accéder à une machine de LAN depuis internet.
Une sortie console série est souvent utilisée sur un système embarqué pour connecter un terminal par liaison série (voir wikipedia, mais en gros c’était les vieux écrans verdadre qu’on voit dans les films des années 70). De nos jour on connecte une autre machine qui émule un terminal. Cela permet de dialoguer directement avec le systéme. Mais si tu ne sais pas ce que c’est, c’est que tu n’en a probablement pas, en tout cas pas visible facilement (parfois sur le circuit imprimé on trouve des broches marquées RX et TX qui permettent au concepteurs de ce connecter via liaison série en phase de développement).

#8

Encore merci de ta réponse.

Je me suis renseigné un peu sur ce qu’était une sortie console série.
En rapport avec le QNAP de ma série, j’ai trouvé ce lien :http://www.cyrius.com/debian/kirkwood/qnap/ts-119/serial.html.
Mais j’ai l’impression que je vais devoir faire quelques achats supplémentaires et de la soudure. Puis cet histoire de U-Boot à la fin…je sais pas, peut-être que c’est facile.
Si je peux éviter ça, ça serait bien quand même sinon !

J’ai testé le branchage/débranchage de l’Ethernet, et j’ai enlevé/remis le Disque Dur mais ça change rien.
J’ai oublié de dire que j’ai testé aussi hier sur un autre ordi (ordi fixe en Ethernet) du réseau, ça fait pareil : “connexion timed out”.

#9

J’ai bien redirigé le port 22 client sur le port XXXX

J’ai du mal à comprendre cette phrase. Normalement sur le client, on lance ssh en indiquant le port à utiliser et sur la box on indique le port à rediriger (mais sans changer le port et sans utilité en local).

Essayes de préciser le port XXXX dans le client si tu as changer 22 en XXXX sur ton serveur.

#10

Salut,

Peut on savoir ce qu’il y a en ligne 19 ?

* edit *

De plus, le mode verbeux dans son intégralité ne serait pas un luxe!

#11

Merci à tous pour votre attention ! ce forum est le meilleur SAV du monde (et gratuit en plus) :laughing:
En plus c’est très instructif, étant assez noob comme vous avez (surement) pu le voir, je me suis peut-être lancé dans l’aventure un peu trop vite.
Je n’ai toujours pas de réponse sur le forum QNAP pour l’instant.

@loreleil

Quand tu dis que tu veux tout le mode verbeux, j’ai tout donné en fait, les 5 lignes. Tu veux savoir les ports et l’adresse ? Si tu veux, je risque rien non ? :smiley:
voici le contenu du ssh_config demandé (côté client donc) :

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no

Quand la console dit la ligne 19, les trucs en commentaire ça compte dans le comptage des lignes ?

@mazarini

Oui la phrase est mal formulé désolé (je viens de comprendre un peu mieux en fait !).
J’ai pas changé le port côté client (c’est toujours le 22), mais je l’ai changé côté serveur. Et j’ai fait une redirection de port du port 22 au port 2818 à l’adresse de destination ip_du_serveur sur la MachinBox. C’est bon non ? En tout cas, ça marchait bien avant.
J’ai tenté de mettre “port XXXX” comme tu me dis dans le ssh_config du client (d’ailleurs pourquoi c’est en commentaire dans le client ?).
Sans succès. J’ai remis port 22 du coup et relaissé en commentaire.

#12

tu as fait une redirection de port à l’intérieur de ton LAN ? C’est ce compliquer la vie pour rien.
Si le serveur écoute sur le port 2818, il te faut utiliser l’option -p 2618.
C’est plus simple que de rediriger un port dans la box.
Je suis d’ailleurs étonné qu’une box fasse de la redirection de port sur un LAN.

#13

Zut, j’ai donné le port ! :laughing: Pas grave, fallait bien que ça arrive…!

@Piratebab

Alors si j’ai bien compris, pour le local en tout cas, je peux enlever toutes les redirections sur la Box, il suffit juste de préciser avec l’option -p et le port ?
En fait, j’ai suivi les tutos que j’ai vu sur le net sans trop me poser de questions (un peu quand même !), j’imagine que c’était pour un accès depuis internet plus tard. Je suis un piètre administrateur je sais…!
En attendant, Je vais me renseigner sur la réinstallation de Debian sur le QNAP sans accès SSH, je la sens pas trop cette histoire…

#14

Re,

Autant pour moi, j’ai zappé sur le clavier.

En fait je voulais dire nano -c /etc/ssh/sshd_config

En ligne 19 ?

Dans quel cas, accentues le debug.

Concernant les ports et autres, ce n’est pas utile. :wink:

#15

Encore merci de votre intérêt à tous !

@loreleil

OK je savais pas pour l’option -vvv.
Voici donc ce que donne la commande ssh -vvv utilisateur@ip_serveur -p XXXX :

root@debian:~# ssh -vvv utilisateur@192.168.X.XX -p XXXX OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.X.XX [192.168.X.XX] port XXXX. debug1: connect to address 192.168.X.XX port XXXX: Connection timed out ssh: connect to host 192.168.X.XX port XXXX: Connection timed out
Y’a une ligne de plus qui est apparue “debug2”.
pour la commande nano -c /etc/ssh/sshd_config
je n’ai pas de sshd_config, mais bien un ssh_config que je t’ai donné tout à l’heure (en tout cas sur le client toujours, le serveur me rappelle plus !).

#16

Que donne:

Une dé-installation malencontreuse ?

#17

Voilà le retour de la commande ls -la /etc/ssh/ :

total 156 drwxr-xr-x 2 root root 4096 sept. 11 13:34 . drwxr-xr-x 151 root root 12288 sept. 26 19:37 .. -rw-r--r-- 1 root root 136156 juin 24 13:50 moduli -rw-r--r-- 1 root root 1669 sept. 26 18:26 ssh_config
Et voici le retour de apt-cache policy openssh-client openssh-server ssh :

openssh-client: Installé : 1:6.0p1-3 Candidat : 1:6.0p1-3 Table de version : *** 1:6.0p1-3 0 500 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages 100 /var/lib/dpkg/status openssh-server: Installé : (aucun) Candidat : 1:6.0p1-3 Table de version : 1:6.0p1-3 0 500 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages ssh: Installé : (aucun) Candidat : 1:6.0p1-3 Table de version : 1:6.0p1-3 0 500 http://ftp.fr.debian.org/debian/ wheezy/main amd64 Packages
Si ça peut t’aider (et m’aider en même temps du coup !). Je dois peut être installer le métapaquet ssh (mais ça va installer ssh-server) ?

#18

Tu es sur de ne pas pouvoir ré-installer ta machine ?
Vu ta manière de la gérer (qui ressemble à la mienne) tu as du mettre un pare-feu qui bloque le port XXXX et oublié de basculer du port 22 au port XXXX dans les règle iptables.

Normalement, il faut d’abord paramétrer ssh et ensuite mettre en place le pare-feu. Le pare-feu se paramètre via un script que l’on lance manuellement lors des premiers tests. Ca permet d’annuler les règles simplement via un reboot. Lorsque ca marche (pour ssh au moins) on peut automatiser le lancement au démarrage. Il faut procéder comme ca également pour les modifications en gardant la possibilité d’annuler via un reboot.

Autrement changer le port 22 en XXXX est souvent conseiller, mais a une utilité très limitée. A mon avis plus d’emmerdement qu’autre chose. J’ai réussi à trouver le port ssh de ma machine facilement avec un outils (nmap ?) sans être un expert. Donc la sécurité apportée…

#19

@mazarini

J’avais paramétré ssh d’abord pourtant (changement de port, PermitRootLogin à No), pour les règles de pare-feu je n’ai pas fait par script. Mais tout allait bien jusqu’à y’a 5 jours. Pourquoi ça aurait marché jusque là alors ?
La dernière chose que j’ai voulu installer et paramétrer, c’était SFTP. Mais je n’ai pourtant pas changé les règles du pare-feu du serveur. J’avais juste ouvert le port 5900 en TDP pour le VNC.
Tu m’as refait penser à la commande nmap que j’avais vu dans un coin du net tiens…! Et bien en effet, il semblerait que mon port SSH soit fermé désormais…pourtant j’avais bien fait attention à ne pas toucher au pare-feu :

[code]root@debian:~# nmap -v 192.168.X.XX

Starting Nmap 6.00 ( http://nmap.org ) at 2012-09-27 09:35 CEST
Initiating ARP Ping Scan at 09:35
Scanning 192.168.X.XX [1 port]
Completed ARP Ping Scan at 09:35, 0.05s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 09:35
Completed Parallel DNS resolution of 1 host. at 09:35, 0.00s elapsed
Initiating SYN Stealth Scan at 09:35
Scanning 192.168.X.XX [1000 ports]
Completed SYN Stealth Scan at 09:35, 4.77s elapsed (1000 total ports)
Nmap scan report for 192.168.X.XX
Host is up (0.0021s latency).
Not shown: 999 filtered ports
PORT STATE SERVICE
5900/tcp closed vnc
MAC Address: XX:XX:XX:XX:XX:XX (ICP Electronics)

Read data files from: /usr/bin/…/share/nmap
Nmap done: 1 IP address (1 host up) scanned in 4.96 seconds
Raw packets sent: 2002 (88.072KB) | Rcvd: 4 (148B)
[/code]
Je n’ai que le port VNC d’ “ouvert”…Comment ça se fait ? Peut-on le “forcer” pour se connecter en SSH :laughing: ?
Je me rappelle avoir ouvert le port VNC avec ufw (ufw enable 5900), j’avais installé Xorg et LXDE sur le serveur pour avoir un environnement graphique aussi.
Sur le net, un certain nombre de personnes disent qu’en effet changer le port SSH n’est pas trop pertinent, surtout avec des logiciels comme fail2ban.
Je crois que je vais me pencher encore plus sur comment réinstaller Debian sur la bestiole…!

Edit : la réinstallation a l’air simple comme bonjour forum.qnap.com/viewtopic.php?p=164164….à condition d’avoir apparemment un accès SSH bien entendu…Ce SSH me sort pas les trous de nez :laughing:
Je vais me renseigner pour une autre manœuvre de réinstallation si possible. L’idée de la sortie console série n’est plus à jeter maintenant…!
Sinon je sens que j’ai claqué des brouzoufs pour rien moi, ça m’apprendra à faire mon admin trop vite et surtout à mettre une Debian direct à la place du système proprio alors que j’y connais rien…

Mais ma motiv’ pour dire “Sus à Big Brother !” un jour est inébranlable, avoir ma propre boite mail, son site, son SFTP…ah le paradis…!!
Si vous ne voyez pas d’autres solutions (j’attends encore d’autres réponses pertinentes sur le forum QNAP), je marquerai “résolu”, en vous remerciant chaleureusement à tous de votre patience !

#20

Je ne sais pas si les ports 22 et XXXX sont fermés ou si personne n’écoute ces ports.

Autrement, tu n’as pas de moyen de réinitialiser ta machine avec l’ancien système ? Tu ne peux pas utiliser vnc pour te connecter à ta machine ? Un reboot est possible ?

Pour ce qui est du controle des ouvertures de ports, j’ai trouvé le paquet knockd qui permet de gérer ca. Maintenant, mon port 22 est toujours fermé et il ne s’ouvre que pendant quelques secondes pour l’ip qui envoie une série de paquets sur des ports prédéfinis. Ca donne une connexion ssh avec la commande : knock mon.domaine.com 1234 4567 7890 && ssh moi@mon.domaine.com. Depuis fail2ban ne détecte plus de tentative de connexion ssh. knock est un programme inclus dans le paquet knockd