Curieux probleme de sécurité au niveau de SSH avec Dolphin

Bonjour à tous,

J’ai un petit probleme de sécurité à vous soumettre:

Etant en train de construire mon serveur actuellement j’ai besoin d’avoir certain dossiers de celui-ci accessibles à distance par l’intermédiaire de Dolphin sous KDE sur un portable itinérant. J’ai donc opté pour une solution “ssh fish” qui, au vu des tutos consultés semblent être la solution la plus simple.

Seulement voila!.. Je constate un méchant problème au niveau de la sécurité qui me laisse quelque peu perplexe: en effet, quand je tape dans le champ d’URL de Dolphin la ligne “fish://@:”, je constate que j’ai un accés direct dans le home de , avec les droits en écritures et ce SANS QUE LE SERVEUR M’EST DEMANDE UN PASSWORD DE QUOI QUE CE SOIT AU MOMENT OU J’Y ACCEDE!!.. Je trouve cela un peu léger tout de même.
Y’aurait-il pas par hasard quelquepart un fichier de config quelconque à paramétrer pour que mon tchi serveur se comporte de manière un peu plus adulte svp?

Merci d’avance.

difficile de savoir sans connaître ton fichier /etc/ssh/sshd_config.

Ou encore le fait que tu as peut être en place une authentification par clef.

et même il demanderait la “passphrase”

Voila le sshd_config:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port <port>
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Il va de soi que dans la ligne port , j’ai bien remplacer par le numéro de port que j’ai attribué à ssh. En fait, à part cela et le “PermitRootLogin yes” que j’ai passé à “no”, j’ai pas modifié grand chose dans la config d’origine

dans ton sshd_config la ligne

ne doit déjà pas être diésée si tu as généré des clés,si tu as des clés il devrait demander la “passphrase” sinon c’est le mot de passe puisque tu l’as autorisé,ton sshd_config a l’air correct.Enlève déjà le dièse et relance le service ssh pour voir si le problème vient de là

De plus ça n’arrête pas de planter: un coup j’ai accés un coup j’ai pas accés, souvent la simple création d’u fichier par le biais de fish tourne completement en rond etc. etc.

Je soupçonne bien un problème de config quelconque mais je ne vois pas ou étant donné que je me suis lancé dans l’aventure du serveur perso que depuis peu.

OK! Je m’exécute et je vous tiens au courant

Rien voilou!.. J’ai carrément pas d’accès du tout: j’ai même pas un message d’erreur la bête tourne simplement en rond. En fait, j’ai l’impression qu’un pare-feu bloque. Pourtant j’ai bien ouvert le port sur la box

Ah! ça y’est!.. Je suis débloqué mais il ne demande toujours pas le password de l’user-distant le vilain!.. Je vais essayer avec konqueror pour voir

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 no

Au 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” :stuck_out_tongue:

pour dolphin la syntaxe c’est

http://doc.ubuntu-fr.org/ssh#authentification

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