Ssh (and thus git) not working in container

LXD
1

This is a transcript of a ssh attempt from container (ubuntu:xenial) to host:

ubuntu@clever-skink:/workspace$ ssh -v mcon@192.168.7.168
OpenSSH_7.2p2 Ubuntu-4ubuntu2.10, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.7.168 [192.168.7.168] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/ubuntu/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.10
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.3 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.7.168:22 as 'mcon'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qn+LkwK3IIfsSjen7t569aXQWirJApMtvAdvLXRs/ZE
debug1: read_passphrase: can't open /dev/tty: No such device or address
Host key verification failed.

Of course /dev/tty is there and it’s world-read/write:

ubuntu@clever-skink:/workspace$ ls -l /dev/tty 
crw-rw-rw- 1 nobody nogroup 5, 0 Aug 19 22:54 /dev/tty

Before launching ssh I had (I’m unsure if this is relevant):

mcon@cinderella:~$ lxc exec clever-skink -- bash
root@clever-skink:~# ls -l /workspace/
total 4
drwxrwxr-x 4 ubuntu ubuntu 4096 Aug 19 13:23 Quectel
root@clever-skink:~# su ubuntu -
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ubuntu@clever-skink:/root$

Note that running the same command as “root” works as expected.

This holds true also for other devices (e.g.: /dev/stderr) which are not usable by “normal user”.
Also using other “tricks” to drop privileges (e.g.: “lxc exec clever-skink – su --login ubuntu”) have similar problems.

What am I doing wrong?

2

Hi,

I’ve confirmed I too am experiencing the issue on both the official ubuntu:xenial image and the LXD-built images:ubuntu/xenial image.

It appears to be an issue with su as you say (as under the hood lxc shell uses the su command as well).

Out of interest, does it work OK if you use the --user flag on lxc exec, e.g.

lxc exec c1 --user=1000 -- bash
ssh ...

For me that works, as this drops privileges without using su.

3

@stgraber @brauner do you know of any known issues with su in Xenial when running in a container?

4

I can confirm.
Using either:

lxc exec c1 --user=1000 -- bash

or logging into container via ssh (bypassing completely lxc exec) works as expected.
Thanks.

1 Like
5

This is a problem with hot terminal allocation works. This depends on glibc helpers such as ttyname_r(), openpty(), and on LXC internals on how to safely allocate terminals all of which would make for a rather long essay. In short, if you’re on a new enough kernel and on a new enough LXC version this issue is fixed.