# sudo: a terminal is required to read the password [SOLVED]

## sliwowitz

On one of my servers, when I log in via ssh, sudo started requiring explicit "-S" otherwise it won't ask for password. This wasn't the case a while ago, but I'm not really sure when it started.

```
$ ssh yggdrasill

admin@yggdrasill ~ $ sudo whoami

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

admin@yggdrasill ~ $ sudo -S whoami

SSH passphrase: 

root
```

The sudo FAQ suggest that 'When running a command via ssh, a terminal is not allocated by default which can cause this message. The "-t" option to ssh will force it to allocate a tty' but that's not my case since I just log in to bash as usual

```
$ ssh yggdrasill

admin@yggdrasill ~ $ tty

/dev/pts/0
```

What could be preventing sudo to read the password the way it used to (that is without needing the "-S" option)?

----------

## mike155

sudo works as expected when I log in to my machine via ssh.

However, if I change the PermitTTY option in /etc/ssh/sshd_conf on my server:

```
PermitTTY no
```

I get exactly the behavior you describe (after restarting the SSH daemon and logging in again).

----------

## sliwowitz

Makes no difference here  :Sad:  I had the PermitTTY line commented out. Explicitly setting it to yes doesn't help either. This is after restarting ssh with the new settings:

```
$ ssh yggdrasill

admin@yggdrasill ~ $ sudo whoami

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

admin@yggdrasill ~ $ sudo -S grep PermitTTY /etc/ssh/sshd_config

SSH passphrase: 

PermitTTY yes

#   PermitTTY no
```

The sshd config file is quite simple (no root, and key-based auth. only). Without comments:

```
# grep ^[^#] /etc/ssh/sshd_config 

Port 2222

PermitRootLogin no

PasswordAuthentication no

UsePAM yes

PermitTTY yes

PrintMotd no

PrintLastLog no

Subsystem   sftp   /usr/lib64/misc/sftp-server

AcceptEnv LANG LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME LANGUAGE LC_ADDRESS LC_IDENTIFICATION LC_MEASUREMENT LC_NAME LC_PAPER LC_TELEPHONE

AcceptEnv COLORTERM
```

----------

## mike155

Please log in with the option "-v -v" (yes, two times "-v"). What does the debug output tell you about the PTY allocation? Do you get any error messages?

On my machine, ssh prints:

```
debug2: PTY allocation request accepted on channel 0
```

Does the output change if you use option '-t' or '-T'?

----------

## sliwowitz

I don't see anything suspicious, the debug2: PTY allocation request accepted on channel 0 is there:

```
$ ssh -v -v yggdrasill

OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c  28 May 2019

debug1: Reading configuration data /home/admin/.ssh/config

debug1: /home/admin/.ssh/config line 1: Applying options for *

debug1: /home/admin/.ssh/config line 45: Applying options for yggdrasill

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 19: Applying options for *

debug2: resolving "XXX.XX" port 2222

debug2: ssh_connect_direct

debug1: Connecting to XXX.XX [XXX.XXX.XXX.XXX] port 2222.

debug1: Connection established.

debug1: identity file /home/admin/.ssh/id_rsa type 0

debug1: identity file /home/admin/.ssh/id_rsa-cert type -1

debug1: identity file /home/admin/.ssh/id_dsa type -1

debug1: identity file /home/admin/.ssh/id_dsa-cert type -1

debug1: identity file /home/admin/.ssh/id_ecdsa type -1

debug1: identity file /home/admin/.ssh/id_ecdsa-cert type -1

debug1: identity file /home/admin/.ssh/id_ed25519 type -1

debug1: identity file /home/admin/.ssh/id_ed25519-cert type -1

debug1: identity file /home/admin/.ssh/id_xmss type -1

debug1: identity file /home/admin/.ssh/id_xmss-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_8.0p1 Ubuntu-6build1

debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0

debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000

debug2: fd 3 setting O_NONBLOCK

debug1: Authenticating to XXX.XX:2222 as 'admin'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug2: local client KEXINIT proposal

debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c

debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa

debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: compression ctos: zlib@openssh.com,zlib,none

debug2: compression stoc: zlib@openssh.com,zlib,none

debug2: languages ctos: 

debug2: languages stoc: 

debug2: first_kex_follows 0 

debug2: reserved 0 

debug2: peer server KEXINIT proposal

debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1

debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519

debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1

debug2: compression ctos: none,zlib@openssh.com

debug2: compression stoc: none,zlib@openssh.com

debug2: languages ctos: 

debug2: languages stoc: 

debug2: first_kex_follows 0 

debug2: reserved 0 

debug1: kex: algorithm: curve25519-sha256

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com

debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XXXXXXX

debug1: checking without port identifier

debug1: Host 'XXX.XX' is known and matches the ECDSA host key.

debug1: Found key in /home/admin/.ssh/known_hosts:22

debug1: found matching key w/out port

debug2: set_newkeys: mode 1

debug1: rekey out after 134217728 blocks

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug2: set_newkeys: mode 0

debug1: rekey in after 134217728 blocks

debug1: Will attempt key: /home/admin/.ssh/id_rsa RSA SHA256:XXXXXXX agent

debug1: Will attempt key: /home/admin/.config/gsconnect/private.pem RSA SHA256:XXXXXXX agent

debug1: Will attempt key: /home/admin/.ssh/id_dsa 

debug1: Will attempt key: /home/admin/.ssh/id_ecdsa 

debug1: Will attempt key: /home/admin/.ssh/id_ed25519 

debug1: Will attempt key: /home/admin/.ssh/id_xmss 

debug2: pubkey_prepare: done

debug1: SSH2_MSG_EXT_INFO received

debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering public key: /home/admin/.ssh/id_rsa RSA SHA256:XXXXXXX agent

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: /home/admin/.ssh/id_rsa RSA SHA256:XXXXXXX agent

debug1: Enabling compression at level 6.

debug1: Authentication succeeded (publickey).

Authenticated to XXX.XX ([XXX.XXX.XXX.XXX]:2222).

debug1: channel 0: new [client-session]

debug2: channel 0: send open

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: pledge: network

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0

debug1: Remote: /home/admin/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding

debug1: Remote: /home/admin/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding

debug2: channel_input_open_confirmation: channel 0: callback start

debug2: fd 3 setting TCP_NODELAY

debug2: client_session2_setup: id 0

debug2: channel 0: request pty-req confirm 1

debug1: Sending environment.

debug1: Sending env LC_ADDRESS = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_NAME = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_MONETARY = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_PAPER = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LANG = en_US.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_IDENTIFICATION = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_TELEPHONE = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_MEASUREMENT = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_TIME = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug1: Sending env LC_NUMERIC = en_GB.UTF-8

debug2: channel 0: request env confirm 0

debug2: channel 0: request shell confirm 1

debug2: channel_input_open_confirmation: channel 0: callback done

debug2: channel 0: open confirm rwindow 0 rmax 32768

debug2: channel_input_status_confirm: type 99 id 0

debug2: PTY allocation request accepted on channel 0

debug2: channel 0: rcvd adjust 2097152

debug2: channel_input_status_confirm: type 99 id 0

debug2: shell request accepted on channel 0

admin@yggdrasill ~ $ sudo whoami

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
```

The output is identical if I use the "-t" option. 

With the "-T" option, three lines in output are missing, otherwise it's the same (I'm just pasting the diff here):

```
@@ -100,7 +100,6 @@

 debug2: channel_input_open_confirmation: channel 0: callback start

 debug2: fd 3 setting TCP_NODELAY

 debug2: client_session2_setup: id 0

-debug2: channel 0: request pty-req confirm 1

 debug1: Sending environment.

 debug1: Sending env LC_ADDRESS = en_GB.UTF-8

 debug2: channel 0: request env confirm 0

@@ -125,8 +124,6 @@

 debug2: channel 0: request shell confirm 1

 debug2: channel_input_open_confirmation: channel 0: callback done

 debug2: channel 0: open confirm rwindow 0 rmax 32768

-debug2: channel_input_status_confirm: type 99 id 0

-debug2: PTY allocation request accepted on channel 0

 debug2: channel 0: rcvd adjust 2097152

 debug2: channel_input_status_confirm: type 99 id 0

 debug2: shell request accepted on channel 0

```

In this case, I'm not getting the terminal at the server at all. That is, I only see the last line of the debug output (debug2: shell request accepted on channel 0), but no prompt at the server - just nothing at all until I kill ssh with ctrl+c.

----------

## sliwowitz

I just noticed that when I run mc and exit it, I get another error which looks kinda related:

```
admin@yggdrasill ~ $ mc

Cannot open master and slave sides of pty: No such file or directory (2)
```

----------

## mike155

I think that your SSH daemon and the SSH connection are fine. Something seems to be wrong on your server 'yggdrasill'.

Does 

```
mount | grep pts
```

 show 

```
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
```

Does 

```
grep tty /etc/group
```

show that tty has gid=5 (or, at least, the same number as shown above in the 'gid' AV-pair?)?

Does 

```
ls -la /dev/ptm*
```

 show 

```
crw-rw-rw- 1 root tty 5, 2 23. Jan 01:03 /dev/ptmx
```

Look especially at the group and at the file mode bits.

----------

## sliwowitz

1. and 2. seem OK

```
admin@yggdrasill ~ $ mount | grep pts

devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)

admin@yggdrasill ~ $ grep tty /etc/group

tty:x:5:
```

but the ownership of /dev/ptmx is different

```
admin@yggdrasill ~ $ ls -la /dev/ptm*

crw------- 1 root root 5, 2 Jan 23 10:36 /dev/ptmx
```

I tired to chgrp tty /dev/ptmx and chmod a+rw /dev/ptmx and re-login, but the sudo error stays the same (also the permission get re-set at reboot). It helped to get rid of the mc error though:

```
admin@thor ~ $ ssh yggdrasill

admin@yggdrasill ~ $ ll /dev/ptmx

crw-rw-rw- 1 root tty 5, 2 Jan 23 10:56 /dev/ptmx

admin@yggdrasill ~ $ sudo -i

sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper

admin@yggdrasill ~ $ mc

admin@yggdrasill ~ $ 
```

----------

## sliwowitz

I tracked it down to the pam_ssh use flag of sys-auth/pambase. Emerging pambase with -pam_ssh solved it. This was probably a leftover setting I copied from a different machine. Since I don't use this one to log in to other machines, I have no need for a private ssh key and therefore don't need pam_ssh style login.

----------

