"Échec de l'écriture: tuyau cassé" lors de la tentative de connexion via ssh avec un utilisateur spécifique
Je tente de configurer un serveur SSHFTP et, lors de la connexion via Apache @ localhost, je suis immédiatement déconnecté avec le message d'erreur "Échec de l'écriture: tuyau cassé". Je peux me connecter correctement avec jack@localhost, mais pas l'utilisateur Apache.
Voici les seuls paramètres que j'ai ajoutés à sshd_config (je ne veux autoriser Apache que lorsque je le fais fonctionner):
Match User Apache
ChrootDirectory /Apache
AllowTCPForwarding no
X11Forwarding no
ForceCommand /usr/lib/openssh/sftp-server
Match
#AllowUsers Apache
Et voici ce que j'ai ajouté à ssh_config:
ServerAliveInterval 120
TCPKeepAlive no
Je me suis assuré que l'utilisateur Apache disposait de toutes les autorisations sur le dossier/Apache et je pouvais me connecter en tant que cet utilisateur sans problème et modifier des éléments dans Terminal. Le dossier ne contient que 2 fichiers: index.html et test.php
Je suis également allé sur un autre ordinateur du réseau et ai utilisé FileZilla pour se connecter en tant qu'utilisateur jack. Cela a bien fonctionné.
Ceci est le journal du terminal lorsque j'essaie de me connecter.
jack@JacksServer:~$ ssh -v Apache@localhost
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 localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/jack/.ssh/id_rsa type -1
debug1: identity file /home/jack/.ssh/id_rsa-cert type -1
debug1: identity file /home/jack/.ssh/id_dsa type -1
debug1: identity file /home/jack/.ssh/id_dsa-cert type -1
debug1: identity file /home/jack/.ssh/id_ecdsa type -1
debug1: identity file /home/jack/.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 bb:f3:74:9d:97:80:89:dc:d9:68:53:5c:f7:25:19:4e
debug1: Host 'localhost' is known and matches the ECDSA Host key.
debug1: Found key in /home/jack/.ssh/known_hosts:1
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
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/jack/.ssh/id_rsa
debug1: Trying private key: /home/jack/.ssh/id_dsa
debug1: Trying private key: /home/jack/.ssh/id_ecdsa
debug1: Next authentication method: password
Apache@localhost's password:
debug1: Authentication succeeded (password).
Authenticated to localhost ([127.0.0.1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
Write failed: Broken pipe
jack@JacksServer:~$
Informations sur la version Ubuntu:
Distributor ID: Ubuntu
Description: Ubuntu 12.04.2 LTS
Release: 12.04
Codename: precise
Modifier:
J'ai lancé la commande Sudo grep -ir ssh /var/log/* et obtenu ceci:
/var/log/auth.log~:Aug 13 16:08:15 JacksServer sshd[32292]: fatal: bad ownership or modes for chroot directory "/Apache"
/var/log/auth.log~:Aug 13 16:08:15 JacksServer sshd[32156]: pam_unix(sshd:session): session closed for user Apache
J'ai essayé de faire chmod 755 /Apache comme certains sites Web l'ont suggéré et de changer de propriétaire, mais je reçois toujours cette erreur. Le dossier appartient actuellement à l'utilisateur Apache.
Quelques informations supplémentaires sur l'utilisateur Apache:
root@JacksServer:/Apache# ls -la /Apache
total 24
drwxr-xr-x 4 Apache root 4096 Aug 13 15:49 .
drwxr-xr-x 29 root root 4096 Aug 13 03:06 ..
drwxr-xr-x 2 Apache nogroup 4096 Aug 13 13:57 .cache
-rw-r--r-- 1 Apache root 5 Aug 13 03:56 index.html
-rw-r--r-- 1 Apache root 0 Aug 13 03:56 index.html~
drwxr-xr-x 8 Apache root 4096 Aug 13 15:51 .ssh
-rw-r--r-- 1 Apache root 20 Aug 13 03:59 test.php
-rw-r--r-- 1 Apache root 0 Aug 13 03:59 test.php~
root@JacksServer:/Apache# ls -la /Apache/.ssh
total 92
drwxr-xr-x 8 Apache root 4096 Aug 13 15:51 .
drwxr-xr-x 4 Apache root 4096 Aug 13 15:49 ..
-rw-r--r-- 1 Apache jack 220 Jun 6 20:08 .bash_logout
drwxr-xr-x 19 Apache jack 4096 Aug 13 15:04 .cache
drwxr-xr-x 3 Apache jack 4096 Jun 6 20:49 .compiz-1
drwxr-xr-x 3 Apache jack 4096 Jun 6 20:22 .dbus
drwxr-xr-x 5 Apache jack 4096 Aug 13 05:37 .gconf
-rw-r----- 1 Apache jack 0 Aug 13 15:47 .gksu.lock
drwxr-xr-x 3 Apache jack 4096 Jun 6 20:22 .local
-rw-r--r-- 1 Apache jack 675 Jun 6 20:08 .profile
-rw------- 1 Apache jack 256 Jun 6 20:22 .Pulse-cookie
drwxr-xr-x 2 Apache jack 4096 Aug 13 14:20 .ssh
-rw------- 1 Apache jack 56 Aug 13 04:45 .Xauthority
-rw------- 1 Apache jack 44215 Aug 13 13:54 .xsession-errors
Les réponses aux deux sont dans ce fil: https://askubuntu.com/questions/134425/how-can-i-chroot-sftp-only-ssh-users-into-their-homes
"Fondamentalement, le répertoire chroot doit appartenir à root et ne peut être un accès en écriture de groupe."
Cela signifie que vous devez vous assurer que votre ChrootDirectory (/Apache) est la propriété de root et ne peut être écrit par aucun groupe/tiers. Ceci est dû à certains risques de sécurité obscurs liés à setuid décrits ici .
Aussi, pour répondre à la question à propos de /bin/false: No such file or directory: Essayez plutôt d'utiliser /sbin/nologin.
J'ai résolu mon problème sous Mac OS X, j'ai changé le
#ClientAliveInterval 0
à
ClientAliveInterval 300
dans/etc/sshd_config après this , et redémarrez la machine, c'est fait.
Posté comme une autre réponse, en raison de sa longueur:
Dans mes conclusions, cette exigence de ChrootDirectory le rend plutôt inutile. Pourquoi le répertoire personnel de quelqu'un ne devrait-il pas être accessible en écriture à cet utilisateur? Boiteux. Les liens symboliques sont également inaccessibles dans Chroot Dirs.
Cependant - j'ai trouvé une solution de contournement astucieuse. J'ai créé un répertoire /home/chroot/outsource dans lequel j'ai utilisé mount --bind pour monter un autre répertoire dans le système /var/www/clients/theclient à /home/chroot/outsource/theclient.
Comme mount --bind n'est que temporaire jusqu'au redémarrage, j'ai ajouté cette ligne dans /etc/fstab:
/var/www/clients/theclient /home/chroot/outsource/theclient none bind,auto,user,noexec 0 0