Forum Clubic

Accès "distant" à un serveur SSH

Bonjour,

J’ai mis “distant”, mais c’est simplement depuis une autre machine sur mon réseau local (tous derrière le même routeur donc).

J’ai installé un Linux Ubuntu Fiery Heron, avec son OpenSSH sur un de mes PCs. Pas de firewall dessus. Depuis ce poste, j’arrive à me connecter en SSH dessus (ssh 127.0.0.1, ou ssh 192.168.0.12 - 192.168.0.12 étant mon poste Ubuntu).

Par contre, depuis mes autres postes, que ce soit depuis un Windows XP (192.168.0.2) avec putty ou un poste Linux Mandrake (192.168.0.126) avec ssh, j’obtiens l’invite pour le nom, je tape mon nom, puis le “prelogin message” apparaît, et le système me demande mon mot de passe. Et là, systématique “Access denied” sous putty, et “Access has been denied” sous Mandrake.

Je suis sûr et certain de ne pas m’être trompé de mot de passe (j’ai essayé de le taper au lieu de l’utilisateur pour être sûr qu’il n’y a pas de problème de clavier ou que sais-je).

Avez-vous des idées pour résoudre ce problème? Je fichier de config est celui de base:

Faut-il recopier des fichiers de clés vers mes autres postes? Je n’avais pas eu besoin de ça pour l’installation sur ma vieille distribution Mandrake…

Merci pour vos avis.

Chankel

Tu as modifié la configuration par défaut?

Si non :
1/ vérifie que l’utilisateur est valide (root ne l’est PAS sur ubuntu)
2/ vérifie que la casse des caractères est correcte

Comme je l’ai marqué, je n’ai PAS changé la config par défaut (j’ai réinstallé totalement et réinstallé 2x), et je n’ai pas de problème de casse, j’ai vérifié en mettant le mot de passe au lieu de l’utilisateur. Et non, l’utilisateur n’est pas root (qui n’existe pas en Ubuntu si je ne m’abuse) :frowning:

et les logs, ils disent quoi ?

Ils disent la même chose:

Quand ça marche:

Quand ça ne marche pas:

Il y a vraiment un pb, il n’y a pas d’utilisateur spécifié pour le login et l’uid 0 est celui de root!

Ceci dit, quand la session s’ouvre correctement (en local sur le PC donc), on me parle aussi de l’uid=0:[quote=""]
session opened for user mathieu by (uid=0)
[/quote]

C’est juste. C’est donc l’uid sous lequel tourne sshd. :confused:

Si je puis me permettre, tu devrais commenter ‘PermitRootLogin yes’. Tu ne devrais jamais accepter une connection distance quelqu’elle soit avec l’utilisateur root.

pour info mon /etc/ssh/sshd_config est reduit a ceci, en enlevant tous les commentaires:

Protocol 2
PasswordAuthentication no
Subsystem       sftp    /usr/lib/misc/sftp-server

Edité le 01/07/2008 à 11:35

jamais de connection en ROOOT !!!
il faut regarder un peu le fichier de config de sshd et permettre la connexion.
Edité le 01/07/2008 à 12:12

Ce n’est pas ce que j’ai dis? :slight_smile:

Interdire la connection en ‘root’ en commentant ‘PermitRootLogin yes’. Ce qui n’est pas le cas dans son fichier de configuration.

Dans son fichier de configuration, il y a des potentielles failles de securite. Comme ‘X11Forwarding yes’ qui devrait aussi etre commente.
D’apres le manpage de ssh:

X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user’s X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring.

A mon avis, le fichier de configuration de sshd devrait etre reduit au strict minimum. Puis, si besoin, petit a petit, ajouter de nouveaux parametres s’ils sont indispensables.
Edité le 01/07/2008 à 12:36

ouais mais ca resout pas son probleme…

pour l’instant, on ne peut pas dire qu’il a des problemes de securite puisqu’il n’arrive meme pas a se connecter

Chankel: est ce que tu as fait des manipulations sur les paquets? en particulier sur la suppression de paquets?

tu peux faire une connexion en mode verbose : -v -v -v

J’ai proposé une solution tres simple, il me semble.
Si ce n’était pas clair, je conseille de le réduire son fichier de configuration au minimum en commentant tout excepté ceci:

Protocol 2
PasswordAuthentication no
Subsystem sftp /usr/lib/openssh/sftp-server

On redemarre le daemon sshd et hop, c’est gagné.
Edité le 01/07/2008 à 14:50

Bon, j’ai réduit sshd_config à sa plus simple expression, mais il doit manquer quelque chose, car maintenant j’obtiens:

Mathieu ou mathieu? :slight_smile:

Le user ‘Mathieu’ n’existe pas sur ton systeme. Essaie ‘mathieu’ sans la majuscule.

Si tu as toujours le message d’erreur, peux-tu poster le resultat de la commande suivante: ‘grep -i mathieu /etc/group’.

[AJOUT] Ajoute aussi ‘UsePAM yes’ dans ton fichier de configuration. Désoléje l’ai oublié et sans ce parametre, sshd n’utilisera pas les users de ton systeme.

Donc au final, ton fichier doit avoir tout commenté excepté ces 4 lignes:

Protocol 2
UsePAM yes
PasswordAuthentication no
Subsystem sftp /usr/lib/openssh/sftp-server

Edité le 01/07/2008 à 18:08

Bon, j’ai essayé un truc et ça a marché. Si quelqu’un a la raison…

J’ai remis mon sshd_config original (celui auquel je n’avais pas touché), et changé mon mot de passe. En effet il y avait un è dedans. Lorsque je le tapais à la place du nom, je voyais bien le è. Mais sans doute que quand je le tapais en mot de passe (en aveugle donc), cela ne fonctionnait pas correctement, car avec un autre mot de passe, miracle! plus aucun problème…

Dommage quand même que les caractères français ne puissent pas être mis dans des mots de passe?

content que tu ais résolu le pb
Hmmm … ils devraient pouvoir?
Peut être un problème utf/iso ?

Tu vois des problèmes d’accents autre part entre les machines client/serveur ssh ?
Par ex. un caractère accentué écrit dans un fichier est correctement vu lorsque tu édite d’un côté et incorrectement de l’autre côté?

+1

Ubuntu est en UTF8.
Mandriva, je sais pas
et Windows, comme toujours, utilise un charset a la con qui n’est pas standard (Windows-1252)

Donc il est tout a fait probable d’avoir un prob a ce niveau…

Je n’en ai pas vus non… Bon j’ai pas tout vérifié non plus!