A priori, sshd démarre mal, tu ne devrais pas avoir le warning.

A ta place :

- je # mv /etc/ssh par /etc/ssh_old
- j'enleverai par dnf remove openssh-server ou réinstall par dnf reinstall openssh-server
ou
- je réinstalle openssh-server

Je regarderai ensuite les différences des fichiers conf
j'ai remove et reinstaller. les fichiers de config etaient identique, j'ai supprimer meme le back up et le repertoire ssh manuellement puis reinstaller 
#systemctl status sshd.service 
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2016-11-02 21:22:08 CST; 4s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 26598 ExecStart=/usr/sbin/sshd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 26600 (sshd)
    Tasks: 1 (limit: 512)
   CGroup: /system.slice/sshd.service
           └─26600 /usr/sbin/sshd

Nov 02 21:22:08 localhost sshd[26600]: Server listening on 0.0.0.0 port 22.
Nov 02 21:22:08 localhost sshd[26600]: Server listening on :: port 22.
Nov 02 21:22:08 localhost systemd[1]: Starting OpenSSH server daemon...
Nov 02 21:22:08 localhost systemd[1]: Started OpenSSH server daemon.
cette pas pas de warning mais toujours le meme probleme de broken_pipe
Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled; vendor preset: disabled)

donc faut activer...

# systemctl start sshd
# systemctl enable sshd
Il a été activé sinon il serait pas "listening" !
oui, mais le service est "disable", le vendor preset : disabled
Active: active (running) since Wed 2016-11-02 21:22:08 CST; 4s ago

4 s ago : reboot ou start stop ? ; Un reboot ferai pas de mal

sur ma bécane : 
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since mer. 2016-11-02 13:49:20 CET; 21h 38min ago
JE viens de refaire un test sur 4VM différentes :

SELINUX : à part si l'on change le port il n'y a aucun problème
Fichier de configuration pourtant même de base si l'on y touche pas il n'y a pas de soucis
Pare feu : à part faire un : 
su -lc 'firewall-cmd --permanent --add-service=ssh && firewall-cmd reload'
Il n'y a pas de souci tant que l'on ne touche pas au port, tu peux le modifier :
1 dans le fichier de configuration de ssh
2 dans le fichier du service sshd.xml disponible dans /usr/lib/firewalld/services (on peut même rajouter d'autre modèles personnalisé) et la commande du pare feu au-dessus est toujours valable (vu que l'on change le port par défaut...), mais il faut le déclarer dans selinux.
3 il est possible de devoir faire le ménage dans le ~/.sshd/... (perso je copie le dossier au cas où), car parfois les clefs ne correspondent plus à l'hôte chez qui tu veux avoir accès.

Non franchement je ne pige pas où est le soucis. A part si tu veux partir plus loin dans le style de supprimer les mdp, mais d'utiliser les clefs (voir la doc ça marche tout seul!), voir des configurations particulières, mais si tu débute commence par ce qui est expliqué dans la documentation!
antbel wrote:oui, mais le service est "disable", le vendor preset : disabled
Ben oui il est disable par defaut, ce qui n'empêche pas de le démarrer manuellement avec un start.
et les ENV tu en fais quoi ? tu ne sais pas quels services et autres sont en temp ?
un reboot remet tout en place;
VINDICATOR a raison, avec les infos reçues , on ne pas faire mieux
Desole mais avec le decallage horaire ...
Je sais pas ou je peux trouver plus d'info j'ai fait
systemctl restart sshd.service
ssh -lmyname localhost
journalctl -u sshd
ce qui donne : 
Nov 04 11:16:37 localhost.localdomain systemd[1]: Stopping OpenSSH server daemon...
Nov 04 11:16:37 localhost.localdomain systemd[1]: Starting OpenSSH server daemon...
Nov 04 11:16:37 localhost.localdomain sshd[27925]: Server listening on 0.0.0.0 port 22.
Nov 04 11:16:37 localhost.localdomain sshd[27925]: Server listening on :: port 22.
Nov 04 11:16:37 localhost.localdomain systemd[1]: Started OpenSSH server daemon.
Nov 04 11:16:43 localhost.localdomain sshd[28060]: Accepted password for myname from 127.0.0.1 port 35862 ssh2
Je ne vois pas plus de renseignements que ca. du moins je ne sais pas ou chercher plus d'info.
@Vendicator SeLinux est pour moi un truc infect ,je vais pas debattre de la chose c'est pas le sujet. il est juste desactiver pour m'assurer de ne jamais avoir affaire a lui,
je l'aurrai bien supprime mais avec les dependances il veut emporter avec lui trop de chose dont certaines que je sais importantes.
Que selinux soit infect ou pas je vois pas le rapport. J'ai juste dit qu'il n’emmerdait pas son monde avec ssh sauf si tu change le port de ssh par défaut.
Tu peux le désactiver quand tu veux de toute manière. Après on vas pas rentrer dans le débat de la sécurité et autres... et c'est vindicators, pas @ venmachin.

Par contre ça correspond à quoi -lmyname (dsl mais j'ai jamais vu alors je pose la question 😉)?

Exemple en me connectant vers une machine virutel :

Chez moi localhost refuse de ce connecter en interne, comme cela ne sert à rien de toute manière...

Sinon en alllant vers une VM (machine virtuel) :
$ ssh root@10.0.0.10
The authenticity of host '10.0.0.10 (10.0.0.10)' can't be established.
ECDSA key fingerprint is SHA256:/nkDQg99j8SgMMezO/mw3o9BSiZysBb+lZO8pCxiw0c.
ECDSA key fingerprint is MD5:1a:ef:73:45:c0:20:75:d6:f6:89:0f:a7:16:d0:b2:28.
Are you sure you want to continue connecting (yes/no)? tes
Please type 'yes' or 'no': yes
Warning: Permanently added '10.0.0.10' (ECDSA) to the list of known hosts.
root@10.0.0.10's password: 
Last login: Sun Oct 30 16:20:26 2016
[root@hades ~]#
Avec une configuration de base par défaut (j'ai pas de besoin particulier sur cette VM, donc la sécurité est minimal) pas de souci.

Pour savoir si cela provient de ta configuration, fait un : 
mv /etc/ssh /etc/ssh-save
systemctl stop sshd
dnf reinstall openssh
systemctl start sshd
setenforce 0
mv .ssh .ssh-save
ssh myname@nommachinequetuveuxatteindre
Explication :
Tu renomme ton répertoire /etc/ssh en /etc/ssh-save (tu sauvegarde ta configuration actuel)
tu stop le service sshd
tu réinstall openssh (à compléter si besoin)
tu désactive temporairement selinux (au cas où) temporairement
Tu démarre le service sshd (il faut utiliser "systemctl enable sshd" pour que ce soit permanent)
tu renomme le .ssh de ton utilisateur en .ssh-save (toujours sauvegarder au cas où!)
tu te connecte sur ta machine en ssh

Si cela ne marche pas, il faut savoir où est la machine pour voir si ce n'est pas simplement le pare feu de ton routeur, modem routeur, firewall matériel, etc... qui bloque. Voir le pare feu de la machine distante.
desole pour la deformation du nom.
Et oui le debat de securite peu etre long dans la mesure ou je fais partie de ceux qui pense que Selinux peut etre eviter et avoir un pc plus ou moin sur. Bref j'ai precise pour dire que Selinux je suis sure n'est pas la cause de mon probleme parceque souvent quand on pose une question il y a des commentaires qui demande de verifier que selinux n'est pas en cause.

pour en revenir a notre sujet, ssh -l user ip == ssh user@ip c'est juste que j'ai l'habitude de l'option -l plutot que @ que je trouve plus long a taper (choix personnel).

je vais aussi preciser que les fedora sur lequel je test sont issus de 2 upgrades de 22 a 23 et 23 a 24 ce sont pas des installes toutes fraiches. et j'aviais deja eu le probleme sur fedora 22 que j'avais regle en mettant une ligne en commentaire dans le fichier /etc/ssh/sshd_conf voir le fil de discussion que je donne lors de mon premier poste.

en suite je me connect a localhost ou alors je tape meme 127.0.0.1 la machine que je veux atteindre c'est la meme.donc a priorie routeur et autre dispositif sont pas concerne. ce que je peux essayer de faire donc (ca va me coute beaucoup) c'est reinstallion de fedora juste pour que sshd marche 😢 car j'ai deja deinstaller openssh-server et openssh et meme supprime les fichiers de conf sans faire backup.

Question ou puis-je trouver plus de log pour sshd ? parce la j'ai rien.
petite manip personnelle quand je modifie une machine cible en utilisant un protocole ssh de communication, c'est d'aller effacer systématiquement dans /home/.ssh/know.hosts la ligne concernant l'IP de la cible.
Je repart avec un certificat neuf. surtout si ta cible est ta propre machine ou sur ton réseau local à la rigueur.
avec sauvegarde préalable. of course
Bonjour,

Je n'ai pas la réponse à ton problème mais je veux bien que tu expliques cette partie là : 
j'ai une ip disons 192.168.1.5 je fais ssh de puis la même machine vers elle même
Je comprends l'utilité d'un ssh vers un autre pc en réseau local ou non, vers une machine virtuelle sur son propre pc, mais vers sa propre machine je n'en comprends pas le but et je ne suis pas contre une explication plus précise, merci.



Sinon à titre personnel j'utilise ssh de manière très simple et toutes les fois où j'ai rencontré des problèmes le mode très verbeux (plus détaillé que -v) m'a beaucoup aidé: 
ssh -vvv



Comme @antbel concernant le fichier ~/.ssh/known_hosts, il m'a fallu parfois le refaire pour me connecter.
J'ai remarqué aussi que les modifications apportées dans le répertoire ~/.ssh/ induisent une latence avant la prise en compte du logiciel Seahorse(Mots de passe et clés) sous Gnome.
En faisant des modifs de clés et du fichier de config je me suis aperçu que Seahorse ne les prenait pas en compte de suite il continuait de se servir des anciennes configurations j'ai donc fais le ménage moi-même dans Seahorse.


PS:
Je ne connaissais pas l'option -l pour ssh, pas mal merci 😉
Je me connect vers moi meme pour m'assurer que ce n'est pas le reseau qui est en cause .
aucune des machines ne se connectamt vers une une autre j'essaie alors de les connecter vers elles memes et ca aussi ca echoue.

oui -vvv c'est utile mais la comme c'est sshd qui bloque et non ssh client la derniere ligne et la meme
en ce qui concerne ~/.shh/known_hosts c'est simple je m'en occupe me pas voici ce que j'en fait: 
rm .ssh/*
la on est sur aussi qu'il n'y a pas d'ennuis venant de la.
À dire vrai je ne comprends pas la logique utilisée, elle est peut-être très bien mais je ne la pige pas du tout.
À ta place j'aurais crée une VM minimale. Avec deux systèmes il me semble que c'est plus simple de trouver les erreurs qu'un système faisant un ssh sur lui-même.
Durant tes essais tu surveilles l'activité sur journalctl . 
journaltcl -f
Autre chose qui peut avoir son importance aussi surtout si tu as fait plusieurs upgrades sur tes autres machines c'est de vérifier la présence de rpmnew, tu as peut-être des fichiers de config ssh ou en relation qui sont incomplets.
Voir le man (rpmnew,rpmsave,rpmorig) & man rpmconf

Allez bon courage!


EDIT:
Désolé en fait il n'y a pas de man rpm{new,save,orig} , uniquement quelques infos sur le net.
Je vais essayer tout ca, au pire des cas si ca marche toujours pas je vais carrement reinstaller une l'une des machine et voir.