Unable to initialize frontend: dialog when using ssh

I am executing the following command over ssh in a testing environment, as root:

ssh <remote_srv> "apt-get autoremove"

In my sshd_config I have "PermitRootLogin without-password" and I have added the id_rsa.pub of root to the authorized_keys file on the remote server.

Nevertheless I get following errors:

debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype

I have looked this up in de man pages of ssh, but couldn't wrap my mind around the explanation on pseudo-terms and ttys.

Is there anybody who can explain above errors? I guess it's a missing option, but which?

Both platforms are Ubuntu 14.04 LTS.

I believe it has something to do with the fact that apt-get autoremove is being run in a non-interactive shell. See Is it possibe to answer dialog questions when installing under docker?

The solution appears to be to prefix the command with DEBIAN_FRONTEND=noninteractive:

ssh <remote_srv> "DEBIAN_FRONTEND=noninteractive apt-get autoremove"

Alex's solution does suppress errors, and he almost got the cause right, but it does not allow you to answer any questions (which is fine when you have preseeded the answers and are running from a script, but real annoying when you are trying new packages). The core issue is an interaction between the assumptions made by ssh and debconf's various frontends.

Let's start with ssh. ssh assumes that when you do not specify a remote command you want a pty on the remote end and that you specify a remote you don't (which works remarkably well 90% of the time, just not this one). This can be overridden by the -t option which forces a pty or the -T option which forces no pty (or the corresponding config file options). Further when using a pty the TERM environment variable is copied (exceptions may apply check documentation for completed details and official sweepstakes entry form). Also of note the -x option disables X11 forwarding and -X enables it.

Debconf itself has no interactivity requirements (by design), but the various frontends do, and each one has different requirements.

I believe the best looking frontend is gnome (there is also a ked front end that I did not get working). The gnome frontend (and the kde one as well) requires some non-default libraries and a X11 server, therefore the command line to force the gnome frontend (once the appropriate libraries are installed) would be

ssh -X <remote_srv> "DEBIAN_FRONTEND=gnome apt-get autoremove"

or if you prefer kde

ssh -X <remote_srv> "DEBIAN_FRONTEND=kde apt-get autoremove"

The dialog frontend (the default) requires a pty and a terminal with a minimum level of functionality specified in the TERM variable (in practice this is anything with a complete terminfo description except dumb).

ssh -t <remote_srv> "TERM=$TERM DEBIAN_FRONTEND=dialog apt-get autoremove"

or

ssh -t <remote_srv> "apt-get autoremove"

the readline frontend has less stringent requirements and will work with dumb terminals, but will need a pty.

ssh -t <remote_srv> "DEBIAN_FRONTEND=readline apt-get autoremove"

The editor frontend depends on an editor which would have specific requirements depending on the editor.

ssh -t <remote_srv> "DEBIAN_FRONTEND=editor EDITOR=vi apt-get autoremove"
ssh -X <remote_srv> "DEBIAN_FRONTEND=editor EDITOR=gvim\ -f apt-get autoremove"

The noninteractive frontend has no requirements but it does not ask any questions (which may or may not be what you want).

ssh <remote_srv> "DEBIAN_FRONTEND=noninteractive apt-get autoremove"