By default, when you run a command on the remote machine using ssh, a TTY is not allocated for the remote session. This lets you transfer binary data, etc. without having to deal with TTY quirks. This is the environment provided for the command executed on computerone.
However, when you run ssh without a remote command, it DOES allocate a TTY, because you are likely to be running a shell session. This is expected by the ssh otheruser@computertwo.com command, but because of the previous explanation, there is no TTY available to that command.
If you want a shell on computertwo, use this instead, which will force TTY allocation during remote execution:
ssh -t user@computerone.com 'ssh otheruser@computertwo.com'
This is typically appropriate when you are eventually running a shell or other interactive process at the end of the ssh chain. If you were going to transfer data, it is neither appropriate nor required to add -t, but then every ssh command would contain a data-producing or -consuming command, like:
ssh user@computerone.com 'ssh otheruser@computertwo.com "cat /boot/vmlinuz"'
отсюда
другими словами, не стоит обращать внимания на эту ерунду. либо есть решения как скрыть ее.