For reasons I do not understand (but see later), your shell is not set to interactive; just issue, on the remote server,
bash -i
this will make the shell interactive and you will be good to go. At this point you may have to source your .bashrc file, because the standard ones are often provided with the following lines, located just at the top of the file:
case $- in
*i*) ;;
*) return;;
esac
This checks whether among the shell flags ($-) there is an i, for interactive; if it is not present, it skips sourcing the file. hence the need to now run
source ~/.bashrc
which will give you your standard environment. I strongly discourage you from executing bash -i automatically, for instance inside your .bashrc file: executing an automatic script that sets the shell to interactive is an oxymoron, and is equivalent to pointing a loaded gun to your temple.
As to why this error message arises, I can only speculate:
your ISP allows a small number of simultaneous PTYs to be allocated to each user; it is for instance GitHub's policy (it allows zero PTYs), but cannot really see the advantage in allowing a small, but non-zero number. But then, there may be someone smarter than I who can cast a light on this...
you are trying to ssh from within a reverse shell, a well-known problem to pentesters. There are ways around it.
it is something related to either the oldish version of Secure Shell Client you are using, or to Windows, but in either case I can be of little help.
ssh -t
or evenssh -tt
.plink
has a-t
option to force a pseudo-tty, which explains why it didn't work. If things are getting worse, have you considered a reboot?putty
instead. Apparently, there is a SSH tree on the left where you can control pseudo-tty allocation. I don't use it myself, so can't confirm/deny :-)