Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
Test de l'ISO d'Ubuntu francophone : nous avons besoin de testeurs pour la version francophone d'Ubuntu 14.04. Liens et informations ici.

#1 Le 20/11/2013, à 09:58

JujuLand

[Résolu] Problèmes SSH

Bonjour,

J'ai installé ssh, et paramétré de la facon suivante (je n'ai mis que ce que j'ai modifié) :

Port 22192
PubkeyAuthentication yes
AuthorizedKeysFile	%h/.ssh/authorized_keys
PasswordAuthentication yes
Banner /etc/issue.net
UsePAM no

J'ai ouvert sur la livebox les ports 22192 et 22180 (pour l'autre ordi) et redirigé respectivement vers l'ip locale de chaque ordi.

SSH_192 	TCP 	22192 	22192 	any 	192.168.1.192 	ACCEPT 	
SSH_180 	TCP 	22180 	22180 	any 	192.168.1.180 	ACCEPT 	

Quand je lance une connexion en local sur le même ordi, c'est ok :

alain@Gramps-JujuLand:~$ ssh -v -X alain@$LOCAL_IP_IP -p 22192
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
ssh: Could not resolve hostname : Name or service not known
alain@Gramps-JujuLand:~$ ssh -v -X alain@$LOCAL_IP -p 22192
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.192 [192.168.1.192] port 22192.
debug1: Connection established.
debug1: identity file /home/alain/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alain/.ssh/id_rsa-cert type -1
debug1: identity file /home/alain/.ssh/id_dsa type -1
debug1: identity file /home/alain/.ssh/id_dsa-cert type -1
debug1: identity file /home/alain/.ssh/id_ecdsa type -1
debug1: identity file /home/alain/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 79:c3:e2:de:dc:69:d0:82:7a:3d:53:2a:81:38:a2:bc
debug1: checking without port identifier
debug1: Host '192.168.1.192' is known and matches the ECDSA host key.
debug1: Found key in /home/alain/.ssh/known_hosts:1
debug1: found matching key w/out port
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.192 ([192.168.1.192]:22192).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LC_PAPER = fr_FR.UTF-8
debug1: Sending env LC_ADDRESS = fr_FR.UTF-8
debug1: Sending env LC_MONETARY = fr_FR.UTF-8
debug1: Sending env LC_NUMERIC = fr_FR.UTF-8
debug1: Sending env LC_TELEPHONE = fr_FR.UTF-8
debug1: Sending env LC_IDENTIFICATION = fr_FR.UTF-8
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending env LC_MEASUREMENT = fr_FR.UTF-8
debug1: Sending env LC_TIME = fr_FR.UTF-8
debug1: Sending env LC_NAME = fr_FR.UTF-8
Last login: Wed Nov 20 08:16:53 2013

Quand je lance en public sur le même ordi ou sur l'autre ordi, j'ai un timeout :

alain@Gramps-JujuLand:~$ ssh -v -X alain@$PUBLIC_IP -p 22192
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to PUBLIC_IP [PUBLIC_IP] port 22192.
debug1: connect to address PUBLIC_IP port 22192: Connection timed out
ssh: connect to host PUBLIC_IP port 22192: Connection timed out

Quand je lance en local sur l'autre ordi, j'ai un 'permission denied (publickey)

alain@Gramps-JujuLand:~$ ssh -X rudy@192.168.1.180 -p 22180
Vous etes chez rudy ...
Permission denied (publickey).

J'ai donc visiblement 2 problèmes:

- problème de clé
- problème de firewall (livebox ?)

Je ne vois plus quoi faire ...

Merci de votre aide
A+

Dernière modification par JujuLand (Le 06/01/2014, à 16:47)

Hors ligne

#2 Le 20/11/2013, à 10:17

JujuLand

Re : [Résolu] Problèmes SSH

Bon, çà avance,

J'ai autorisé les mots de passe et relancé le serveur
La connexion en local a fonctionné, et j'ai pu passer en donnant le mot d epasse de l'utilisateur
J'ai envoyé ma clé
J'ai ensuite interdit les mots de passe
Et là, çà fonctionne avec la passphrase.

Mais c'est toujours pareil en passant par l'adresse ip publique.

A+

Hors ligne

#3 Le 20/11/2013, à 11:35

JujuLand

Re : [Résolu] Problèmes SSH

J'ai autorisé les password, pour voir si çà améliorait.

J'ai essayé aussi, sachant que chaque serveur était lancé sur un port spécifique, de ne pas faire de redirection depuis le firewall de la livebox, pensant que de toute façon, chaque serveur scrutant un port qui lui est propre, chaque serveur prendrait ce qui lui convient.

SSH_180 	TCP 	22180 	22180 	any 	any 	ACCEPT 	
SSH_192 	TCP 	22192 	22192 	any 	any 	ACCEPT 	

Malheureusement, çà ne change rien.

alain@Gramps-JujuLand:~$ ssh -v -X alain@$PUBLIC_IP -p 22192
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to PUBLIC_IP [PUBLIC_IP] port 22192.
debug1: connect to address PUBLIC_IP port 22192: Connection timed out
ssh: connect to host PUBLIC_IP port 22192: Connection timed out

Si quelqu'un a une idée ?
Peut-être qu'il n'est pas possible d'attaquer une même adresse IP en sortie et en entrée ?

A+

Dernière modification par ljere (Le 21/11/2013, à 14:33)

Hors ligne

#4 Le 20/11/2013, à 12:14

Tamarou

Re : [Résolu] Problèmes SSH

Bonjour, tu veux dire que tu tente de tester ton accès ssh sur ton IP publique à partir d'un poste de ton réseau local ?

Dernière modification par Tamarou (Le 20/11/2013, à 12:15)


Utilisateur d'Archlinux/Xfce et Xubuntu 14.04

Hors ligne

#5 Le 20/11/2013, à 12:41

jplemoine

Re : [Résolu] Problèmes SSH

Attention : sauf erreur de ma part, tu ne peux pas accéder à l'adresse publique depuis ton réseau local.
(faire une boucle).


Cordialement, Jean-Philippe.
Sous Ubuntu en système principal depuis 2009
Ubuntu 14.04 desktop (2 postes) & server (1 poste)

Hors ligne

#6 Le 20/11/2013, à 13:42

JujuLand

Re : [Résolu] Problèmes SSH

J'avais bien un doute sur la possibilité de se mordre la queue ...
Donc logiquement, puisque çà passe en local d'ordi à ordi, çà devrait être ok ?

Est-ce que le paramétrage du firewall de la box doit être avec redirection ? ou peut-il être any any, sachant que les deux serveurs écoutent des ports distincts ?

Merci
A+

Hors ligne

#7 Le 20/11/2013, à 14:14

jplemoine

Re : [Résolu] Problèmes SSH

non. sur la box, il faut ajouter les NAT/PAT. C'est à dire vers quel ordinateur il faut envoyer le flux venant du port désigné.
Exemple :
- Si port 80, aller sur PC1 port 80
- Si port 8080, aller sur PC2 port 80.
Normalement, il n'y a pas besoin de toucher au pare-feu.


Cordialement, Jean-Philippe.
Sous Ubuntu en système principal depuis 2009
Ubuntu 14.04 desktop (2 postes) & server (1 poste)

Hors ligne

#8 Le 21/11/2013, à 10:50

JujuLand

Re : [Résolu] Problèmes SSH

Bon, j'ai fait une tentative d'install sur l'ordi s'un copain, mais malheureusement à distance, et je n'ai donc pas pu tester, vu que çà ne fonctionnait pas.
Je vais essayer sur un ordi plus proche, et je ferai l'install moi-même.

Pour ce qui est du firewall de la box, même si on fait une redirection par NAT pour atteindre le bon ordi, il me semble qu'il faut de plus ouvrir les port concernés dans le firewall de la box, car la box, avant de faire la redirection filtre.

Quand j'aurai avancé, je vous tiens au courant.

Merci
A+

Hors ligne

#9 Le 21/11/2013, à 11:02

Tamarou

Re : [Résolu] Problèmes SSH

Pour ce qui est du firewall de la box, même si on fait une redirection par NAT pour atteindre le bon ordi, il me semble qu'il faut de plus ouvrir les port concernés dans le firewall de la box,

Dans la box, les ports s'ouvrent en faisant une redirection. Tu penses qu'il a encore un autre filtre dans la tienne ?

Par contre, sur le serveur, le firewall n'est pas indispensable en ipv4, la box suffit pour le protéger.
Enfin tu as choisi de faire écouter le serveur sur un port différent du 22, vérifie que cela est bien pris en compte dans ta redirection.


Utilisateur d'Archlinux/Xfce et Xubuntu 14.04

Hors ligne

#10 Le 21/11/2013, à 11:52

JujuLand

Re : [Résolu] Problèmes SSH

Dans la box, les ports s'ouvrent en faisant une redirection. Tu penses qu'il a encore un autre filtre dans la tienne ?

Ma foi, j'en sais rien, je ne pensais pas que çà ouvrait le port. Je pourrais confirmer ou infirmer après l'install chez un copain.

Par contre, sur le serveur, le firewall n'est pas indispensable en ipv4, la box suffit pour le protéger.

Je n'ai pas touché au firewall des micros serveurs, et dans la mesure où çà passe entre deux ordis du même réseau local, on peut supposer que le paramétrage du firewall des-dits ordis (que je n'ai, je le redis, pas touché) est correct.

Enfin tu as choisi de faire écouter le serveur sur un port différent du 22, vérifie que cela est bien pris en compte dans ta redirection.

Je pense être un débutant, car je n'ai que 4 ans d'utilisation intensive de Linux, mais si je faisais ce genre de balourdises, je pense que je devrais jeter l'ordi aux orties ... wink

A+

Dernière modification par JujuLand (Le 21/11/2013, à 11:56)

Hors ligne

#11 Le 21/11/2013, à 12:18

ljere

Re : [Résolu] Problèmes SSH

jplemoine a écrit :

Attention : sauf erreur de ma part, tu ne peux pas accéder à l'adresse publique depuis ton réseau local.
(faire une boucle).

je ne vois vraiment ce qui empêcherait de faire une boucle, pour l'avoir testé je sais que c'est réalisable, il faut par contre avoir fait la redirection de ton port que tu utilises vers l'ip cible interne sur ta box


Modérateur d'ubuntu-fr.org
athlon 2800+, nvidia FX5200 et 2 Go de ram et sempron 3000+, ati radeon et 1 Go de ram sur voyager 12.04 32 bit
Toshiba satellite_c670d-11l sur openbox/xubuntu 14.04 64 bit
Mon Blog et Une découverte

Hors ligne

#12 Le 21/11/2013, à 12:18

Tamarou

Re : [Résolu] Problèmes SSH

je pense que je devrais jeter l'ordi aux orties ... wink

C'est pas sympa pour les orties, tu pourrais aussi en faire une bonne soupe big_smile


Utilisateur d'Archlinux/Xfce et Xubuntu 14.04

Hors ligne

#13 Le 21/11/2013, à 12:33

Tamarou

Re : [Résolu] Problèmes SSH

ljere a écrit :

il faut par contre avoir fait la redirection de ton port que tu utilises vers l'ip cible interne sur ta box

C'est intéressant comme pratique. Veux-tu en dire plus sur la façon de faire cette redirection stp ? Merci


Utilisateur d'Archlinux/Xfce et Xubuntu 14.04

Hors ligne

#14 Le 21/11/2013, à 13:48

ljere

Re : [Résolu] Problèmes SSH

voici un lien qui explique assez clairement la méthode à employer http://fr.openclassrooms.com/informatiq … on-routeur


Modérateur d'ubuntu-fr.org
athlon 2800+, nvidia FX5200 et 2 Go de ram et sempron 3000+, ati radeon et 1 Go de ram sur voyager 12.04 32 bit
Toshiba satellite_c670d-11l sur openbox/xubuntu 14.04 64 bit
Mon Blog et Une découverte

Hors ligne

#15 Le 21/11/2013, à 13:56

Tamarou

Re : [Résolu] Problèmes SSH

Merci, mais je n'y trouve rien qui concerne au accès à un serveur local, à partir du réseau local et en utilisant l'ip publique.
Comment faut-il comprendre cette page ?


Utilisateur d'Archlinux/Xfce et Xubuntu 14.04

Hors ligne

#16 Le 21/11/2013, à 13:59

JujuLand

Re : [Résolu] Problèmes SSH

C'est ce qu'il me semblait, même si j'avais des doutes.
Mais quand j'essaye de sortir, j'ai systématiquement un timeout, en boucle sur le même ordi, ou sur l'autre ordi du réseau local ...

Bref, je ne savais plus trop... car avant en cours d'édition de ce post, et juste avant de l'envoyer, je viens de refaire un essai en boucle sur le même ordi avec l'adresse publique, et çà ... fonctionne. Plus de timeout ...

Pour récupérer les adresses ip locales, j'ai rajouté çà dans .bashrc:

# Added by JujuLand to easily retrieve local and public IP address
export LOCAL_IP=$(ifconfig eth0 | grep "inet adr" | cut -d: -f2 | awk '{print $1}')
export PUBLIC_IP=$(w3m -dump icanhazip.com)

Et bien sûr, je me sers de ces variables dans mes tentatives de connexion.
Maintenant que çà fonctionne, avec le recul, je me suis aperçu hier, sans que çà fasse tilt, que l'adresse publique avait changée.
Comme .bashrc n'est lancé qu'à la première utilisation de bash (donc pendant la connexion), la variable n'avait pas la bonne valeur, et je me suis fait avoir comme un bleu, les timeout venant probablement de là.
Je mettrai çà aussi dans un shell afin de pouvoir le relancer à discrétion.

alain@Gramps-JujuLand:~$ ssh -v -X alain@$PUBLIC_IP -p 22192
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to PUBLIC_IP [PUBLIC_IP] port 22192.
debug1: Connection established.
debug1: identity file /home/alain/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alain/.ssh/id_rsa-cert type -1
debug1: identity file /home/alain/.ssh/id_dsa type -1
debug1: identity file /home/alain/.ssh/id_dsa-cert type -1
debug1: identity file /home/alain/.ssh/id_ecdsa type -1
debug1: identity file /home/alain/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 79:c3:e2:de:dc:69:d0:82:7a:3d:53:2a:81:38:a2:bc
debug1: checking without port identifier
The authenticity of host '[PUBLIC_IP]:22192 ([PUBLIC_IP]:22192)' can't be established.
ECDSA key fingerprint is 79:c3:e2:de:dc:69:d0:82:7a:3d:53:2a:81:38:a2:bc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[PUBLIC_IP]:22192' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to PUBLIC_IP ([PUBLIC_IP]:22192).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LC_PAPER = fr_FR.UTF-8
debug1: Sending env LC_ADDRESS = fr_FR.UTF-8
debug1: Sending env LC_MONETARY = fr_FR.UTF-8
debug1: Sending env LC_NUMERIC = fr_FR.UTF-8
debug1: Sending env LC_TELEPHONE = fr_FR.UTF-8
debug1: Sending env LC_IDENTIFICATION = fr_FR.UTF-8
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending env LC_MEASUREMENT = fr_FR.UTF-8
debug1: Sending env LC_TIME = fr_FR.UTF-8
debug1: Sending env LC_NAME = fr_FR.UTF-8
Last login: Thu Nov 21 09:02:13 2013
alain@Gramps-JujuLand:~$

Je viens de plus de réessayer en dévalidant l'authentification par mot de passe, et çà fonctionne.
Idem depuis un ordi ver l'autre par internet.

Super ...
Y'a pu ka voir ce qu'à bricolé le copain pour que çà ne fonctionne pas ...

Merci
A+

ljere: j'ai remplacé ton ip par PUBLIC_IP dans ton log

Dernière modification par ljere (Le 21/11/2013, à 14:31)

Hors ligne

#17 Le 21/11/2013, à 14:02

ljere

Re : [Résolu] Problèmes SSH

je vais expliquer comment j'ai procéder
donc sur ma free j'ai fait une redirection du port 22 sur mon serveur adresse 192.168.0.10 en tcp
ensuite au lieu de me connecter comme habituellement

ssh ljere@192.168.0.10

je me connecte sur mon ip extérieur

ssh ljere@***.***.**.**

Modérateur d'ubuntu-fr.org
athlon 2800+, nvidia FX5200 et 2 Go de ram et sempron 3000+, ati radeon et 1 Go de ram sur voyager 12.04 32 bit
Toshiba satellite_c670d-11l sur openbox/xubuntu 14.04 64 bit
Mon Blog et Une découverte

Hors ligne

#18 Le 21/11/2013, à 14:06

Nasman

Re : [Résolu] Problèmes SSH

On peux aussi changer le port de la freebox par un port plus exotique car je pense que le port 22 est attaqué en priorité


PC fixe et portable avec Precise 64 bits

Hors ligne

#19 Le 21/11/2013, à 14:15

Tamarou

Re : [Résolu] Problèmes SSH

Merci. on va pas polluer le sujet de JujuLand. Il a réglé son problème et c'est bien pour lui.
J'en ouvre un autre car sur ma box sfr cela ne fonctionne pas.

Dernière modification par Tamarou (Le 21/11/2013, à 17:01)


Utilisateur d'Archlinux/Xfce et Xubuntu 14.04

Hors ligne

#20 Le 21/11/2013, à 14:21

JujuLand

Re : [Résolu] Problèmes SSH

C'est intéressant comme pratique. Veux-tu en dire plus sur la façon de faire cette redirection stp ? Merci

Dans la box, tu dois avoir un menu de configuration réseau qui te permet de faire du NAT.
Il suffit de déclarer un port, un protocole, et une adresse ip pour diriger le traffic lié à ce port vers une adresse ip

Sur une livebox 1 par exemple:
Configuration > Avancée > Routeur

Service personnalisé SSH_192                                           SSH_180
Protocole                   TCP                                                   TCP
Port externe              22192                                                 22180
Port interne               22192                                                 22180
IP du serveur            192.144.1.192                                     192.168.1.180

Ceci permettant de différencier les ordis, en réception, alors que l'adresse ip publique est la même.

A+

Hors ligne

#21 Le 21/11/2013, à 15:11

JujuLand

Re : [Résolu] Problèmes SSH

Je viens de mettre en ligne un petit shell pour installer et tester ssh sous Ubuntu.

Sur mon site web

Merci pour l'aide et à bientôt.

A+

Hors ligne

#22 Le 21/11/2013, à 18:33

JujuLand

Re : [Résolu] Problèmes SSH

Je confirme ce qui a été dit plutôt par Tamarou, concernant le firewall des livebox:

Les 2 règles sont maintenant créées et apparaissent dans la liste Routeur - NAT.
A noter que les règles de routage NAT ouvrent automatiquement les ports associés dans le firewall de la borne Inventel. Inutile donc de configurer quoi que ce soit au niveau des autorisations du Pare-feu de votre point d'accès Inventel.

Pourquoi se fatiguer quand on peut l'éviter smile

A+

Hors ligne

#23 Le 05/01/2014, à 21:24

JujuLand

Re : [Résolu] Problèmes SSH

Un nouveau problème que je n'avais pas remarqué auparavant, en m'auto-connectant à travers le réseau local ou internet:

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to xx.xx.xxx.xx [xx.xx.xxx.xx] port xxxxx.
debug1: Connection established.
debug1: identity file /home/alain/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alain/.ssh/id_rsa-cert type -1
debug1: identity file /home/alain/.ssh/id_dsa type -1
debug1: identity file /home/alain/.ssh/id_dsa-cert type -1
debug1: identity file /home/alain/.ssh/id_ecdsa type -1
debug1: identity file /home/alain/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: checking without port identifier
The authenticity of host '[xx.xx.xxx.xx]:xxxxx ([xx.xx.xxx.xx]:xxxxx)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[xx.xx.xxx.xx]:xxxxx' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/alain/.ssh/id_dsa
debug1: Trying private key: /home/alain/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).

J'autorise uniquement les connexion avec clé
Si j'autorise les connexions avec mot de passe, en entrant le mot de passe de mon utilisateur Ubuntu, çà fonctionne, mais ce n'est pas ce que je veux.
Çà a fonctionné, je ne sais pas quand çà a commencé à merder.
Je ne me rappelle pas avoir modifié quelque chose ...

Il me semble que çà a commencé quand j'ai essayé d'attaquer mon ordi portable qui a le même nom d'utilisateur, et pour lequel j'avais mis la même phrase pour la clé.
Si je compare la connexion en local qui avait fonctionné et celle-ci qui foire, c'est par là que ca change:
Succès:

Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.192 ([192.168.1.192]:22192).

Echec:

Bonjour ... Vous arrivez sur JujuLand
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug1: Authentications that can continue: publickey

Si vous avez une idée ...

Merci
A+

Dernière modification par JujuLand (Le 05/01/2014, à 21:38)

Hors ligne

#24 Le 06/01/2014, à 10:24

JujuLand

Re : [Résolu] Problèmes SSH

Bonjour,

J'ai bien noté ta réponse, mais l'essai ne semble pas concluant:

alain@Gramps-JujuLand:~$ ssh -p 22192 -i /home/alain/.ssh/id_rsa alain@$PUBLIC_IP
Bonjour ... Vous arrivez sur JujuLand
Permission denied (publickey).
alain@Gramps-JujuLand:~$ ssh -p 22192 -i /home/alain/.ssh/id_rsa alain@$LOCAL_IP
Bonjour ... Vous arrivez sur JujuLand
Permission denied (publickey).

Pour ce qui est de çà:

autre possibité: editer le fichier config  dans .ssh

Je ne sais pas trop quen penser, et je me pose la question de savoir si sa raison d'être n'est que pour des connexions sur le LAN, ou même à travers le WAN.
Et de plus si c'est uniquement dans le cas d'une boucle ou pour des connexions plus classiques d'ordi à ordi.
Dans ce cas, celà doit-il être sur l'appelant ou sur l'appelé ?
Si c'est sur l'appelant, çà me sera impossible, vu que j'ai un certain nombre d'ordis à maintenir.
De plus, je n'ai pas ce fichier dans .ssh

Je dois dire que la dernière remarque me laisse perplexe:

pour tester ta re_direction de port du routeur  (et non pas le nat qui est autre chose)

J'ai consulté çà : http://fr.wikipedia.org/wiki/Redirection_de_port , et çà semble me dire que NAT et redirection sont la même chose.

Dans le même ordre d'idée, si je fait un test par l'adresse ip publique, est-ce que je passe par le fai, ou ma box re-route-elle directement sur mon adresse locale ?

Enfin, j'ai essayé ta commande, et çà semble ok:

alain@Gramps-JujuLand:~$ sudo nc -vv -r -z -i 2 $LOCAL_IP 22192
Connection to 192.168.1.192 22192 port [tcp/*] succeeded!
alain@Gramps-JujuLand:~$ sudo nc -vv -r -z -i 2 $PUBLIC_IP 22192
Connection to 90.30.197.60 22192 port [tcp/*] succeeded!

Qu'en conclure ?

Enfin dernière question:
Si j'autorise les mots de passe, il semblerait qu'entre mot de passe et passphrase, quand la clé est enregistrée dans authorized_keys, la connexion soit bien validée par la saisie de la passphrase, qu'en est-il quand la connexion vient d'un utilisateur qui n'est pas connu dans authorized_keys ? Serait-ce juste le mot de passe de l'utilisateur local ?

Merci
A+

Dernière modification par JujuLand (Le 06/01/2014, à 10:56)

Hors ligne

#25 Le 06/01/2014, à 12:11

JujuLand

Re : [Résolu] Problèmes SSH

Je viens de vérifier, car j'avais un doute, mais j'ai bien RSAAuthentication à yes
J'avais une tabulation à la place d'un espace sur la ligne concernant le fichier authorized_keys, j'ai remplacé par un espace, et comme je le pensais, çà n'a rien change.
La connexion échoue toujours
Je mets le sshd_config, au cas où j'aurais merdé ailleurs

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

# What ports, IPs and protocols we listen for
Port 22192
# 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 no

# 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 no

J'ai bien les id_rsa et id_rsa.pub:

alain@Gramps-JujuLand:~$ ls -ail .ssh
total 36
10486241 drwx------   2 alain alain  4096 janv.  6 09:25 .
10485761 drwxr-xr-x 168 alain alain 12288 janv.  6 08:29 ..
10489946 -rw-rw-r--   1 alain alain   403 janv.  1 18:24 authorized_keys
10485885 -rw-------   1 alain alain  1766 janv.  5 17:41 id_rsa
10501955 -rw-r--r--   1 alain alain   403 janv.  5 17:41 id_rsa.pub
10489039 -rw-r--r--   1 alain alain    36 déc.   9 15:17 issue.net
10486674 -rw-r--r--   1 alain alain   444 janv.  5 20:12 known_hosts

Par contre, je suis surpris de la différence de taille entre id_rsa et id_rsa.pub.
Pour le authorized_keys, on voit qu'il fait la même taille que le id_rsa.pub
Je colle de cette façon:

alain@Gramps-JujuLand:~$ echo $(cat ~/.ssh/id_rsa.pub) >> ~/.ssh/authorized_keys

En ce qui concerne Wikipedia et même la config des livebox, il y a donc un amalgame un peu abusif.

si je dois me connecter 50 fois par jour sur mon serveur ssh
je préfère saisir  ssh toto    que    ssh -i ma_clé  toto@adresse_serveur
c'est donc fonctionnel autant en local que distant.

Donc çà doit être positionné sur le client pour que toto soit bien connu.
Cà ne reviendrait pas à réinventer le hosts ?
Et si c'est bien coté client, pour plusieurs connexion différentes possibles, celà serait-il suffisant ?

PasswordAuthentication no 
IdentityFile ~/.ssh/id_rsa

avec bien sur la nécessité de définir l'adresse dans la ligne de commande.

Tu n'as pas répondu à ma question concernant les utilisateurs n'ayant pas de clés, utilisent-ils le mot de passe de l'utilisateur local ?
Cà ne serait pas top en terme de sécurité, vu que sur des ordis persos (ce ne sont pas des serveurs), les gens mettent des mots de passe simples.

Merci
A+

Dernière modification par JujuLand (Le 06/01/2014, à 12:12)

Hors ligne

Haut de page ↑