Connexion ssh très longue
Résolu
Bonjour
J'ai un linux centos 7. Je veux configurer un serveur ssh dessus pour faire du transfert de donnée chiffré . J'ai mis la clé de mon serveur sur le pc et depuis mon serveur j'essaye d'accéder avec la commande
Pouvez-vous m'aider s'il vous plaît ?
J'ai un linux centos 7. Je veux configurer un serveur ssh dessus pour faire du transfert de donnée chiffré . J'ai mis la clé de mon serveur sur le pc et depuis mon serveur j'essaye d'accéder avec la commande
ssh root@ip. Cela fonctionne sans me demander le mot de passe comme convenu mais après un délai très long. Je suis passé en mode
-v, mais je ne sais pas comme comprendre ce qui ne va pas.
Pouvez-vous m'aider s'il vous plaît ?
OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 58: Applying options for *
debug1: Connecting to ip [ip] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.63:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: ***@*** MAC: <implicit> compression: none
debug1: kex: client->server cipher: ***@*** MAC: <implicit> compression: none
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: kex: curve25519-sha256 need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:6AdxkZ4Wg9bhligStg1sQFvn0FE4PS84tAlnXjK+ZRI
debug1: Host 'ip' is known and matches the ED25519 host key.
debug1: Found key in /etc/ssh/ssh_known_hosts:18
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug1: Authentication succeeded (publickey).
Authenticated to ip ([ip]:22).
debug1: channel 0: new [client-session]
debug1: Requesting ***@***
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype ***@*** want_reply 0
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
Last login: Tue Jun 22 10:16:36 2021 from **.**.**.**
A voir également:
- X11uselocalhost no
- Gmail connexion - Guide
- Connexion chromecast - Guide
- Gmail connexion autre compte - Guide
- Ssh download - Télécharger - Divers Web & Internet
- Site inaccessible n'autorise pas la connexion - Guide
2 réponses
Bonjour,
C'est probablement dû à l'option
Si la ligne
Remarques
Bonne chance
C'est probablement dû à l'option
UseDNSdéfinie dans
/etc/ssh/sshd_config.
Si la ligne
UseDNS Yesfigure dedans :
- 1. Ouvre ce fichier avec des droits superutilisateur (e.g.
sudo nano /etc/ssh/sshd_config
). - 2. Commente cette ligne, en ajoutant un
#
en début de ligne, ou corrige-la enUseDNS yes
. - 3. Sauve et quitte (ctrl x, dans
nano
)? - 4. Relance le serveur ssh (
sudo systemctl restart sshd.service
) pour que le changement de configuration soit pris en compte. - 5. Réessaie de te connecter à ton serveur ssh.
Remarques
- Tu indiques que tu te connectes avec l'utilisateur
root
. C'est une mauvaise idée, surtout si la machine est accessible publiquement, car le profil root existe sur toute machine linux, a un maximum de droit, et donc est une cible de choix pour un attaquant. C'est la raison pour laquelle un serveur ssh bien configuré interdit ce genre de connexion (toujours dans/etc/ssh/sshd_config
, voirPermitRootLogin no
). - Tu utilises des clés ssh, c'est très bien, c'est plus sûr et plus propre que par mot de passe. Si tu ne prévois que ce genre d'authentification, tu peux activer l'option
PasswordAuthentication no
dans/etc/ssh/sshd_config
. - Pour un maximum de sécurité, tu peux finaliser ton installation avec
fail2ban
.
Bonne chance
Bonjour Tom,
Ton fichier de configuration me paraît correct, mais essaye de mettre explicitement
Exemple : Ici ma machine s'appelle
À titre indicatif, voici le contenu de
Bonne chance
Ton fichier de configuration me paraît correct, mais essaye de mettre explicitement
UseDNS no. Vérifie aussi que le nom de ta machine est défini dans
/etc/hosts.
Exemple : Ici ma machine s'appelle
silkcomme indiqué par la commande
hostname, et je retrouve bien cette entrée dans
/etc/hosts.
(mando@silk) (~) $ grep $(hostname) /etc/hosts
127.0.1.1 silk
À titre indicatif, voici le contenu de
/etc/ssh/sshd_configdéfini sur l'un des serveurs que je gère (voir
grep -v ^# /etc/ssh/sshd_config | grep -v ^$) :
Include /etc/ssh/sshd_config.d/*.conf
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
Bonne chance
Merci pour ton aide
La ligne était déja commentée ;( Par rapport à root, je suis sur un réseau privé non connecté au net et j'utilise une connexion par clé ssh.
Voici une copie de mon fichier :
Merci beaucoup j'ai enlevé le # et mis sur no est ça fonctionne.
Merci merci
je te souhaite une super journée
et merci pour tout tes conseils
De rien, en fait j'ai déjà eu ce problème par le passé, c'est pour ça :-)
Bonne continuation et excellente journée également