par la même occasion fais voir aussi le fichier client ssh_config,as tu généré des clés? ou uniquement passwd pour te connecter?
Konqueror est plus bavard pour le coup! Mais là je suis bloqué: voila ce qui s’affiche:
Il est impossible d'achever l'opération demandée
La connexion a été refusée par le serveur
Détails de la requête :
URL : fish://<user-distant>@<domain.com>
Protocole : fish
Date et heure : lundi 19 mai 2014 23:39
Informations supplémentaires : <domain.com>
Description :
Le serveur <domain.com> a rejeté la tentative de connexion de cet ordinateur.
Causes possibles :
Le serveur, bien que connecté à l'Internet, n'a peut-être pas été configuré pour autoriser les requêtes.
Le serveur, bien que connecté à l'Internet, n'exécute peut-être pas le service demandé (fish).
Un pare-feu (périphérique servant à restreindre les requêtes d'accès réseau), protégeant votre réseau ou celui du serveur, est peut-être intervenu, faisant obstacle à votre requête.
Solutions possibles :
Réessayez, maintenant ou plus tard.
Contactez l'administrateur du serveur pour une aide plus approfondie.
Contactez votre assistance technique, qu'il s'agisse de votre administrateur système ou d'un groupe d'assistance technique, pour une aide plus approfondie.Bon!.. Le pare-feu, le voila:
# Interdire toute connexion entrante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
echo - Interdire toute connexion entrante : [OK]
# Interdire toute connexion sortante
iptables -t filter -P OUTPUT DROP
echo - Interdire toute connexion sortante : [OK]
# Vider les tables actuelles
iptables -t filter -F
iptables -t filter -X
echo - Vidage des tables : [OK]
# Ne pas casser les connexions etablies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
echo - Ne pas casser les connexions établies : [OK]
# Autoriser les requetes DNS, FTP, HTTP, NTP
iptables -t filter -A OUTPUT -p tcp --dport 21 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -t filter -A OUTPUT -p udp --dport 123 -j ACCEPT
echo - Autoriser les requetes DNS, FTP, HTTP : [OK]
# Autoriser loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
echo - Autoriser loopback : [OK]
# Autoriser ping
iptables -t filter -A INPUT -p icmp -j ACCEPT
iptables -t filter -A OUTPUT -p icmp -j ACCEPT
echo - Autoriser ping : [OK]
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
echo - Autoriser serveur Apache sur ports non sécurisés : [OK]
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
echo - Autoriser serveur Apache sur ports sécurisés : [OK]
#Partie concernant SSH:
iptables -t filter -A INPUT -p tcp --dport <port> -m recent --rcheck --seconds 60 --hitcount 2 --name SSH -j LOG --log-prefix "SSH REJECT"
iptables -t filter -A INPUT -p tcp --dport <port> -m recent --update --seconds 60 --hitcount 2 --name SSH -j DROP
iptables -t filter -A INPUT -p tcp --dport <port> -m state --state NEW -m recent --set --name SSH -j ACCEPT
En fait il est directement inspiré du tuto de la “fermeduweb” et il n’est pas encore finalisé. Enfin, le serveur est situé derrière une box dont les ports indiqués dans le parefeu sont ouvert. Mais le probleme se présente même en test local (c’est à dire en indiquant mon adresse IP locale au lieu du nom de domaine). Et de toute façon je ne vois pas en quoi le parefeu pourrait avoir quelquechose à voir dans la non-demande du password
Voila le ssh_config du client (poste sous ubuntu)
moduli sshd_config ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub
ssh_config ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key ssh_import_id
francois@TCHII:/etc/ssh$ cat ssh_config
# 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 noAu sujet des clefs, non je n’en ai pas générer. En console je me connecte avec password sans aucun problème
as tu changé le port ssh par défaut?
Si oui la requête doit être de la forme
où xxxx est le port ssh
quand je veux me connecter en ssh graphique j’utilise nautilus,pcmanfm ne veut pas fonctionner.Il faut aussi configurer ssh_config pour le port,le passwd et les options que tu veux utiliser pour ta connection
Oui le port par defaut a été changé (c’est pourquoi je l’ai effacé dans mes posts). La commande dont tu parles est manifestement pour la console. Ors sur celle-ci, je n’ai absolument aucun souci. Tout baigne comme il faut. C’est lorsque je veux accéder par “Dolphin” ou “konqueror” que le problème se présente en utilisant “fish”: (dans le champ URL: “fish://@:”) désolé de garder encore mes vieux réflexes “windobiens” mais il m’est pour ma part plus pratique de modifier un fichier texte par l’intermédiaire d’un éditeur type “kate” plutôt que “nano” 
A marcastro:
Ah une piste!.. Tu parles de quel ssh_config, marcastro? Celui du client ou celui du serveur? Excuses-moi de poser des questions idiotes mais je débute là, dans l’utilisation de ssh!.. et les tutos que j’ai consulté ne parlaient pas de modifier quoi que ce soit sur le poste client et tous ne parlaient que d’un seul fichier de configuration: sshd_config sur le serveur
Par sftp voila le message que m’envoie Dolphin:
Impossible de trouver la clé hôte pour ce serveur mais un autre type de clé existe.
Un attaquant pourrait changer la clé par défaut du serveur pour faire croire au client que la clé n'existe pas.
Veuillez contacter votre administrateur système./etc/ssh/sshd_config —> config du serveur
/etc/ssh/ssh_config —> config du client
[quote=“fanch33”]Par sftp voila le message que m’envoie Dolphin:
Impossible de trouver la clé hôte pour ce serveur mais un autre type de clé existe.
Un attaquant pourrait changer la clé par défaut du serveur pour faire croire au client que la clé n'existe pas.
Veuillez contacter votre administrateur système.
[/quote]
tu ouvres le fichier ~/.ssh/known_hosts et tu supprimes ce qui est dedans et tu relances la demande de connection
Voila! c’est fait!
OK! apres avoir vider le fameux fichier.ssh/known_hosts, sftp fonctionne super bien plusieurs fois de suite.
Mais, par acquis de conscience, je reessaye “fish”!.. et celui-ci ACCEDE COMME A MON DOSSIER DISTANT SANS PASSWORD ce qui me permet d’y écrire ou d’effacer un fichier (ce qui n’est pas logique) , et après… Plantage!.. Ni fish ni sftp ne fonctionne et ce pendant un petit moment (en fait, je soupçonne maintenant mon parefeu d’y etre bien pour quelque chose puisque celui-ci bannit en principe une mauvaise connexion pendant un certain délai)
J’en profite au passage pour signaler ce qu’il me semble être une très bonne doc sur SSH. En tout cas, elle est clair et précise contrairement à beaucoup que j’ai lu jusqu’à présent:
http://www.linuxpedia.fr/doku.php/commande/ssh
Bon!.. Résumons!..
Le problème se pose maintenant autrement:
POINT 1: par sftp, grace à toi marcastro (louange à toi), ça fonctionne comme je le souhaite (c.a.d. que le serveur, à chaque accès sftp, me demande bien le password de <user_distant>, ce qui me semble être la moindre des choses, ma maman m’ayant défendu de parler avec des inconnus.
POINT 2: En revanche par “fish”, aucune demande de password n’est demandé lors d’un premier accès, on accède directement au disque sans aucune protection ce qui permet à un inconnu d’aller bidouiller sans aucun complexe dans mes fichiers (par exemple modifier un fichier php sensible sur mon site). En revanche il y a un phénomène de plantage récurrent une fois la manip faite.
POINT 3: Dans ces plantages, je soupçonne en fait le pare-feu à la sauce “fermeduweb” d’en être le responsable: en effet, selon le concepteur du site (http://www.lafermeduweb.net/billet/tutorial-creer-un-serveur-web-complet-sous-debian-5-backup-securite-197.html#secu) le protocole SSH est en principe bloqué pendant un laps de temps donné (60 secondes) après trois tentatives d’accés illégales. Ors j’ai bien constaté que si les bugs apparaissaient lors du premier accès par “fish” (qui est fatalement un accès illégal puisque pas de password), ils disparaissaient quelques temps après (la théorie est à tester en enlevant le parefeu)
Du coup, une solution à mon problème parait plutôt évidente au “newbie” que je suis: y’a-t-il un moyen de bloquer côté serveur l’accés par “fish” tout en permettant l’accés par sftp et si oui, lequel?
Je vous remercie pour vos suggestions
simplement tu n’utilises plus "fish"utilise nautilus c’est le gestionnaire par excellence,je n’ai jamais eu de plantage avec lui.Tu devrais bien lire le lien que je t’ai fourni plus haut,le lien sur ubuntu.Tu peux te connecter aussi en utilisant filezilla,marche très bien aussi
autre chose,tu dis:
si tu es derrière une box alors le pare feu de la box est suffisant,je m’en contente pour mon ssh, changement de port et redirection des ports dans la box et jamais de tentatives d’intrusions.
Il faut savoir également que tu ne peux te connecter que en local avec ton adresse réseau en faisant
si tu fais
ça tournera dans le vide.
Pour te connecter de l’exterieur pour tester tu vas là
Excuses-moi, Marcastro mais ton dernier post appelle de ma part un certain nombre de précision:
PRIMO
A priori on peut parfaitement se connecter à distance par SSH par le biais de
"ssh @ -p ". D’ailleurs le site que tu m’indiques a bien testé de manière positive la connexion. Pas de problème ça marche donc. D’ailleurs je gère depuis chez moi un autre PC appartenant à un pote de cette manière-là. Donc la méthode est éprouvé. Il suffit pour cela d’avoir une adresse IP public fixe et un nom de domaine enregistré. C’est mon cas. En revanche c’est vrai que les accés sont fortement ralentis mais cela suffit largement pour modifier par exemple un fichier texte ou consulter un PDF quelconque.
SECUNDO:
La présence d’un deuxieme pare-feu semblerait saugrenue si elle ne tenait pas en ces deux raisons précises:
1 - le pare-feu de la box (bien qu’il soit plutôt pas mal paramétrable sur une Freebox V6) ne permet pas ce que permet iptables au niveau du serveur (par exemple la possibilité d’explulser une IP inconnue pratiquant le brute-force. cf par exemple les lignes concernant SSH qui bannient un utilisateur pendant 60 secondes si 3 tentatives d’accés sont rejetées: c’est peut-être beaucoup de précaution après le changement du port d’accés SSH mais ça, ça me tranquilise.
2 - As-tu des gamins âgés entre 15 et 18 ans chez toi qui possèdent également un PC (sous Windows) et qui attendent justement que tu ais le dos tourné pour transformer le serveur en seedbox avec bittorrent ou Amule qui télécharge à donf? Moi si!.. Le pire c’est que mon fiston est aussi passionné que moi d’informatique mais il n’a pas du tout les mêmes connaissances!.. A cause de lui je me suis déjà mangé deux avertissement ADOPI. En plus, il a trois amis adorables certes mais qui sont de véritables graines de “hacker” (malheureusement dans le sens péjoratif du terme compte tenu que comme beaucoup de gosses de leur âge, ils ne savent pas ce qu’ils font). Ors le serveur est destiné à un usage FAMILIALE et LEGAL (blog perso, mailbox, gallerie photos, cloud à l’usage EXCLUSIF des membres de la famille et quelques amis et serveur multimedia): il s’agit d’un vieux PC de bureau récupéré et légèrement modifié: dualCore avec 4Go de RAM et 2To de disques. Comme tu le vois, il y aura pas mal de choses dessus et je dois donc le protéger quelque peu: mon fils sait très bien paramétrer le pare-feu de la box et il ne s’est pas gêné pour le faire quand il a installer Bittorent sur sa machine (cause des deux lettres ADOPI). En revanche le iptables du serveur, pour lui c’est du chinois!.. En ce qui me concerne j’ai la prétention d’en comprendre beaucoup plus que lui bien que cela soit certainement peu par rapport à d’autres qui fréquentent ce forum (d’ou d’ailleurs ma présence ici)
TERTIO:
Pour en revenir à l’usage de “fish”: Oui effectivement, je ne l’utiliserai plus puisque sftp marche mieux.
Mais il n’empêche que le problème ne sera pas supprimé pour autant puisque quelqu’un d’autre PEUT LE FAIRE et ça, ça me dérange!.. D’autant plus que, en admettant effectivement que par le plus grand des hasards ce quelqu’un d’autre ait pu avoir connaissance du port SSH de ma machine (que j’ai bien fait exprès de ne pas révéler ici), il se retrouvera dans la même situation que moi, c’est-à-dire avec un accès total en écriture SANS PASSWORD sur un répertoire qui par définition ne lui appartient pas. Moi, j’appelle cela ni plus ni moins qu’une ENORME faille de sécurité et j’estime qu’elle n’a rien à faire sur un serveur: bien que je sois d’accord avec toi sur l’improbablitié de son exploitation, il n’empêche qu’elle existe!..
Du coup j’en reviens donc à ma question précédente, laquelle s’exprime en ces termes bien précis: peut-on AU NIVEAU DU SERVEUR (et non pas au niveau du poste), condamner l’usage de “fish” tout en laissant le protocole sftp accessible de façon à justement supprimer cette faille qui n’a pas lieu d’être, ce qui me laisserai ainsi un minimum de confort puisque j’utiliserai mon gestionnaire de fichier habituel, celui-ci étant Dolphin étant pour ma part un utilisateur de KDE depuis maintenant 10 ans et non pas un utilisateur GNOME (vraisemblablement contrairement à toi, Marcastro puisque tu utilise Nautilus)? Tout cela est bien entendu dit en dehors de toute considération trollesque “GNOME versus KDE” puisque ces deux environnement graphique proposent exactement les mêmes fonctionalités.
Nota: je m’excuse platement pour la longueur excessive de mes phrases et le côté direct qui me caractérise et qui est pourtant à prendre au troisième voire même quatrième degré
je saisis bien tes arguments mais je ne comprends pas pourquoi dolphin ne demande pas de passwd.Je viens de l’installer chez moi pour tester et dolphin sur ma machine me demande bien le mot de passe quand je lance sftp,alors que se passe il chez toi?Mauvaise installation?lancer dolphin en ligne de commande pour voir si il y a des erreurs
Oui!.. sftp me demande bien le mot de passe lui aussi chez moi. Mais pas “fish”!.. C’est là qu’est le blem!. Essayes avec fish STP la synthaxe est la meme:
fish://@:
Quand à l’idée de lancer Dolphin par une console, c’est une bonne idée, je le fais
Par fish, donc en ligne de commande cette fois-ci, lorsque je valide la ligne "dolphin fish://@:port la console répond:
Object::connect: No such signal org::freedesktop::UPower::DeviceAdded(QDBusObjectPath)
Object::connect: No such signal org::freedesktop::UPower::DeviceRemoved(QDBusObjectPath)
"/org/freedesktop/UDisks2/drives/Optiarc_DVD_RW_AD_7591S_1065216Q11" : property "Drive" does not exist
"/org/freedesktop/UDisks2/drives/HGST_HTS541010A9E680_J8400076HT7LHC" : property "Drive" does not exist
"/org/freedesktop/UDisks2/drives/HGST_HTS541010A9E680_J8400076HT7LHC" : property "DeviceNumber" does not exist
"/org/freedesktop/UDisks2/drives/HGST_HTS541010A9E680_J8400076HT7LHC" : property "Device" does not exist Mais je suis bien dans le dossier perso de sur le serveur, SANS qu’il m’est demandé le mot de passe, avec un droit en écriture dans ce dossier ce qui me permet d’y créer un fichier “toto”. Si je quitte Dolphin et que je le relance, J’ai le même message qui s’affiche dans la console mais cette fois ci, je n’ai plus accés au dossier et ça pédalle dans la semoule. j’attends un peu et j’essaye avec sftp
Et donc, toujours en ligne de commande je balance Dolphin qui lance sftp://@: et là!.. Surprise!.. Tout marche correctement (c.a.d. qu’il demande bien le password)… mais le meme message apparait dans la console!..
Oui, je pense effectivement un problème de conf mais je vois pas où…