Csdrhrt

I have a Linux-VPS, using it as GIT- and HTTP-Server.

HTTP: Apache

Git-server: git-http-backend via vhost

When i log me in via SSH, everything is fine.
But if i open a second SSH-Connection , i get this error:

stdin: is not a tty

I use ssh for years and have never seen such an error.. I searched around for over 1.5 hours..

** While i wrote this, the error gots even more strange - now the error comes on every connection!

I havent found any solution that helped me..

Im using..

• Windows


• Secure Shell Client (quite outdatet, but much nicer than putty)

Are you "chaining" ssh connections? That may be the cause. I think https://unix.stackexchange.com/questions/48527/ssh-inside-ssh-fails-with-stdin-is-not-a-tty is relevant.

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:

1. 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...




2. you are trying to ssh from within a reverse shell, a well-known problem to pentesters. There are ways around it.




3. 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.