code. grind. sleep.

Tag - SSH

Fil des billets - Fil des commentaires

vendredi 21 octobre 2011

X11 forwarding request failed on channel 0

Par Orgrim le vendredi 21 octobre 2011, 12:43 - NetBSD

Quand j'essaye de me logguer sur ma box NetBSD fraichement passé en X.org modular, j'ai ça :

orgrim@serfouette ~ $ ssh rateau 
X11 forwarding request failed on channel 0
Last login: Fri Oct 21 12:20:24 2011 from serfouette.home.orgrim.net

WTF? ça tombe en marche SSH normalement.

Et bien le souci vient de l'échange des magic cookies pour l'authentification entre serveurs X à travers SSH, c'est utilisé par le X11 forwarding et on a besoin de plusieurs choses pour ça :

  • le chemin complet vers xauth sur le client
  • le chemin complet vers xauth sur le serveur
  • Avoir X11Forward yes sur le serveur quand on le demande sur le client (il vaut yes dans le /etc/ssh/ssh_config du client par flemme de taper -X sur la ligne de commande)

Le client est sous Linux, donc pas de soucis le chemin en dur /usr/bin/xauth dans le binaire sshd marche. Par contre pour NetBSD avec du X.org modular, il faut décommenter l'option XAuthLocation dans /etc/ssh/sshd_config et /etc/ssh/ssh_config pour donner le bon chemin vers xauth, comme indiqué en commentaire dans ces deux fichiers :

# If you use xorg from pkgsrc then uncomment the following line.
#  XAuthLocation /usr/pkg/bin/xauth

Enfin, comme le X11Forward est à no par défaut sur NetBSD, je l'ai activé. La vrai solution est de faire ça côté client en utilisant explicitement l'option -X quand on veut ouvrir des fenêtres sur le serveur.

Le pire c'est que Google ne sort rien sur le message "X11 forwarding request failed on channel 0", à part une question sans réponse sur un stackoverflow-like en Russe !

3 commentaires aucun rétrolien

samedi 26 février 2011

Accès SSH externe sur une gateway NetBSD

Par Orgrim le samedi 26 février 2011, 19:19 - NetBSD

Pour permettre l'accès à la gateway depuis Internet avec un maximum de sécurité, j'ai configuré le serveur OpenSSH (fournit dans basesys) et PF pour :

  • N'autoriser l'accès que par clé publique
  • Empêcher les attaques par force brute sur le serveur

La configuration d'OpenSSH peut se faire de deux façon :

  1. On désactive l'authentification par mot de passe et l'utilisation de PAM pour que la méthode keyboard-ineractive ne laisse rien passer
  2. On désactive l'authentification par mot de passe et le challenge/respone pour garder l'utilisation de PAM

J'ai choisi la 2ème méthode qui permet de garder la fonctionnalité de pam_nologin (seul root peut se logguer si /etc/nologin existe, en modifiant /etc/ssh/sshd_config :

PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePam yes

Ainsi, l'authentification par mot de passe est totalement désactivée.

Pour empêcher les attaques par force brute sur le serveur, on configure PF de cette façon :

  • Il faut une table pour enregistrer les IP à bannir
  • On utilise l'option max-src-conn-rate sur la règle qui ouvre le port de SSH : pas plus de deux connexions dans un intervalle de dix secondes par IP.
  • On ajoute une règle pour bloquer les IP présentes de la table

Les règles PF, à placer dans /etc/pf.conf :

table <ssh_bans> persist

# allow ssh on the external interface, limit to connections in ten seconds
pass in on $ext_if inet proto tcp to ($ext_if) port ssh \
    keep state (max-src-conn-rate 2/10, overload <ssh_bans> flush)

# reject banned ip from connectiong to ssh port
block return in on $ext_if inet proto tcp from <ssh_bans> to ($ext_if) port ssh

Pour surveiller, on utilise les options de manipulation des tables de pfctl :

# pfctl -t ssh_bans -T show
# pfctl -t ssh_bans -T add X.Y.Z.T
# pfctl -t ssh_bans -T delete X.Y.Z.T

Enfin, un petit thread qui explique à quoi sert le challenge/response et la méthode keyboard-interactive : http://groups.google.com/group/comp...

un commentaire aucun rétrolien