Changing the behavior of ssh
When you run ssh without a command and there is a local pseudo-terminal, the tool allocates a pseudo-terminal on the remote side automatically. Usually you access an interactive remote shell this way, so allocating a terminal is the right thing to do.
When you provide a remote command to ssh, it assumes the command is not interactive. It doesn't provide a pseudo-terminal to the command. This happens in your case, sudo finds no terminal.
You can explicitly tell local ssh to allocate a pseudo-terminal on the remote side:
-t
Force pseudo-terminal allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g. when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.
(source)
ssh -t user@hostIPAddress "cd /opt/somewhere && sh -v -v ./install.sh"
Note when you do this, you can no longer tell the stdout and stderr of ./install.sh apart locally. Read the "broader picture" part of this another answer of mine.
Changing the behavior of sudo
sudo suggests alternative solutions that depend solely on sudo itself:
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
These are:
- read from standard input:
sudo -S (see this answer);
- configure an askpass helper:
sudo -A (see the second part of this answer).
Both require an argument to sudo, so you would need to change the script. It's easy to lessen security by using any of these options. Strongly prefer ssh -t. Note in general sudo may be configured not to work without a terminal anyway.