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 no
