et
idem : “???”
id_rsa déplacée (pas généré de clefs DSA).
même résultat
Quel horreur !!!
Que contient cette horreur ?
~ $ cat /home/jarlax/etc_ssh_ssh_configD’ou sort-il ?
Chaise/Clavier 
Oups ! t’as rien vu ! d’ailleur, il est viré, et édité ^^
Je fais une pause, j’ai besoin d’y voir clair, … et j’éditerai ce dernier sitôt la reprise
En attendant, expliques nous exactement comment tu as procédé la Suppression/Réinstall ?
Fichiers et répertoires en rm, etc la totale, please
Et je vais devoir aller manger. Le bureau commence à bouger… et j’ai même pas terminé mon taf ! argh !
Bon soit je suis trop lent, soit vous êtes trop rapide 
,
le temps de poster ma réponse y avait deja moult réponses entre temps !
pour le “roaming” c’est l’itinérance dans les telecom, mais pour ssh je ne sait pas, tu utilise la 3g pour te connecter au net/serveur ? (on sait jamais …)
Et un user peut très bien ajouter des clefs dans ~/.ssh/authorized_keys (sur serveur distant), une fois qu’il a réussi à ce connecter a son compte (distant), avec un mot de passe par ex.
@BelZéButh “le dernier mot” c’était pour l’étoile
edit après qq. tests, quand ça fonctionne, j’ai ce genre de sortie (avec le mode verbeux -v)
Donc apparemment c’est juste une info qu’il affiche toujours pour le “roaming”.
Le cas ou il demande un mot de passe, (malgré la/les clefs présentes) c’est quand il y a un pb. de config. avec les clefs dans ~/.ssh/authorized_keys (sur le serveur distant) . on ne ce pose pas trop de questions quand tout fonctionne 
ssh user@exemple.com -v -p 50022
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to exemple.com [87.**.**.**] port 50022.
debug1: Connection established.
debug1: identity file /home/ben/.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/ben/.ssh/id_rsa-cert type -1
debug1: identity file /home/ben/.ssh/id_dsa type -1
debug1: identity file /home/ben/.ssh/id_dsa-cert type -1
debug1: identity file /home/ben/.ssh/id_ecdsa type -1
debug1: identity file /home/ben/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze3
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze3 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA cc:67:***
debug1: Host '[exemple.com]:50022' is known and matches the RSA host key.
debug1: Found key in /home/ben/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: [b]Roaming not allowed by server[/b]
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/ben/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to exemple.com ([87.**.**.**]:50022).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
Linux *.ovh.net 3.8.13-xxxx-grs-ipv6-64 #2 SMP Fri May 17 05:55:51 CEST 2013 x86_64 GNU/LinuxQuand quelqu’un post en même temps, mon “envoie” bloque, et je me retrouve aussi avec 4 posts de retards ^^
Pour le roaming, je n’utilise pas de 3g. J’utilise wicd… mais je crois qu’il me fait des gatouilles.
En tout cas, j’aimerai avoir un mode roaming actif et efficace. Mais j’ouvrirai un post sur le sujet (j’en ai plein à ouvrir ^^)
[quote=“scyd”]Bon soit je suis trop lent, soit vous êtes trop rapide ,
le temps de poster ma réponse y avait deja moult réponses entre temps !
pour le “roaming” c’est l’itinérance dans les telecom, mais pour ssh je ne sait pas, tu utilise la 3g pour te connecter au net/serveur ? (on sait jamais …)
@BelZéButh “le dernier mot” c’était pour l’étoile[/quote]
Pour l’itinérance, je connais, je suis chez FreeMobile 
mais dans le cas présent ?
Pour les fichiers se terminant par ‘*’, je confirme, ce sont les exécutables.
Ah ? Je te poserai des questions sur FreeMobile, ça peut m’intéresser.
Non, j’utilise des wifi publics, hotspots sfr, free, etc., ou encore des portails publics (universités, …)
Je confirme … 
@jarlax ?
[quote=“BelZéButh”]
En attendant, expliques nous exactement comment tu as procédé la Suppression/Réinstall ?
Fichiers et répertoires en rm, etc la totale, please[/quote]
Si tu as encore le temps, là …
Ce que je fait pour ajouter une clef à un compte user sur un serveur distant, évidement il faut le mot de passe du compte en question (distant)! en étant connecté avec le compte user local qui me servira ensuite bien entendu.
$ ssh-copy-id -i ~/.ssh/id_rsa.pub user@ip.ou.tld et un (une fois connecté au compte distant)
donne un truc du genre :
petite correction …
[quote]debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jarlax/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/jarlax/.ssh/id_dsa
debug1: Trying private key: /home/jarlax/.ssh/id_ecdsa
debug1: Next authentication method: password[/quote]
Il me semble, qu’il recherche une clé ou un mdp.
Mais il ne serait trop ou aller chercher cette info, voir même aucune confirmation (clé ou un mdp).
sshd_config ?
Le fichier sshd_config m’apparaît être indispensable.
Extrait :
[quote]~ # cat /etc/ssh/sshd_config
…
Port 22
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
Autoriser ou non la connexion par clé publique. Par défaut, cette option est sur « yes ».
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys
AuthorizedKeysFile /root/.ssh/authorized_keys
To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
AllowUsers XXX
AllowGroups XXXX
[/quote]
Suis-je dans l’erreur …
- edit *
[quote]debug1: Authentication succeeded (publickey).
Authenticated to exemple.com ([87...**]:50022).[/quote]
?
si jarlax connaît son mot de passe (distant) ça vaut le coup de tester avec “ssh-copy-id”, pour copier sa clef sur le serveur, ssh-copy-id est fait pour ça .
Erf par contre il n’a pas voulu me prendre un autre port que le 22 avec …
citation du man :
Suivant la config. du serveur, faut que le repertoire et le fichier cité, ne soit accessible que pour l’user concerné (et ce n’est pas forcement une mauvaise idée indépendamment de la config du serveur d’ailleurs)
trop pressé peut être ^^
Et si d’autre client peuvent ce connecter sans soucis, ce serait plutôt du coté jarlax qu’il y a un pb de config. a mon humble avis, ceci dit je suis pas non plus un expert de ssh …
edit:
[quote]debug1: Authentication succeeded (publickey).
Authenticated to exemple.com ([87...**]:50022).[/quote]
J’ai poster ça pour voir des différences lors d’une connexion réussi avec une clef et le fameux “roaming”
N’est-ce pas simplement le serveur distant qui est en faute ?
[quote]debug1: Authentication succeeded (publickey).
Authenticated to exemple.com ([87...**]:50022).[/quote]
Le port 50022 ?
Je ne comprends pas.
Quand tu a la main sur le fichier de conf du serveur, tu peut mettre le port que tu veut, changer du 22 vers autre chose ça évite déjà pas mal de scans (de robots & qui pourrissent les logs en plus, oui je connais aussi fail2ban).
Proposition.
Il y a un moyen de lever toute hypothèse/suspicion/etc … concernant la config de l’ami jarlax ou celle du serveur_labas.
@jarlax je t’ouvre une porte ssh sur l’un de mes serveurs ovh. N’ayant de mon côté aucun souci …
Ceci sur le port 22. Une copie de ta clé en mp, mon ip et nous serons fixé, peut être …
oulah ! ça fait beaucoup de posts à répondre ça !
Concenrnant la désinstallation, j’ai fait :
[code]# aptitude purge openssh-client
aptitude update
aptitude install openssh-client[/code]Certes, je n’ai pas modifier davantage le ~/.ssh, je peux le déplacer tout simplement en backup en attendant.
Pour ce qui est du /etc/ssh/sshd_config, il n’est pas généré même après la réinstallation. Reprenant ce que j’ai compris du propos de Ricardo, ce fichier est lié à l’installation du serveur, pas du côté client…
@belzébuth:
Pour ce qui est d’un accès ssh, c’est très gentil de ta part.
Nous pourrons garder cette possibilité si rien ne marche.
Pour ce qui est du port 22, je me connecte via un portail qui le filtrera, donc ce serait uniquement via le 443.
Je rappelle que je n’ai pas d’accès au serveur distant. Et comme je ne peux m’y connecter, je ne vois pas comment y modifier des fichiers.
L’admin m’a précisé qu’il regarderait ce soir…
[quote=“jarlax”]…
L’admin m’a précisé qu’il regarderait ce soir…[/quote]
Alors, je pense que toute supputation supplémentaire est superflue, tant que l’on n’a pas la réponse dudit admin.
99 chances sur 100 que ce soit un défaut de configuration ‘sshd_config’ du serveur.
Pour le 1 % restant, je vois une mauvaise transcription de la clef pub ou à un mauvais endroit.
@ Jarlax :
Tu ne peux pas lui demander la copie du fichier sshd_config, même avec les données sensibles cachées à l’aide d’XXX ?
Ok, je vais essayer d’obtenir la config de son sshd_config.
Assurément, les données seront masquées, je m’y efforce.