I am using a Macbook SSH terminal and generated RSA key pairs and uploaded remote id_rsa.pub with approved permissions. I can connect with remote Apache web server. I can create, open, move, modify and on preliminary inspection can manage files on the web server, no problem ... and generate no error messages.

Surprisingly I can not scp a folder nor document from my desktop to the remote server. Nor can I scp a folder or document from the remote server to my desktop. Each time I receive the error message:

stdin: is not a tty

The scp command to or from the remote web server does not work with either absolute or relative file location references.

My standard syntax looks like this:

From local host:

scp -rp ~/Desktop/foldername username@secureremoteserver.com:~/public_html

From remote host:

scp -rp username@secureremoteserver.com:~/public_html/foldername ~/Desktop/

It appears to be an issue with the stdin: is not a tty error message.

What's going on?

If this error is preventing the file transfers, how do I resolve the stdin: is not a tty?

  • Yes I tried full path and every permutation, same error with rsync. – user2217265 Mar 29 '13 at 17:18
  • Server does not recognize my local desktop for these commands ... I assume the 'stdin: is not a tty' error message is definitely at the root of the problem. -- thanks, cb – user2217265 Mar 29 '13 at 17:20
  • please edit your post to include that information. – strugee Nov 18 '13 at 7:02
  • Please try scp -v (verbose mode) and post its output. – n.st Dec 25 '13 at 15:36
  • Oops, this one's old! My suggestion still applies, though, if you haven't found a solution yet. – n.st Dec 25 '13 at 15:37

The reason for this is that one of the login scripts on the target server is using stty... to set up terminal characteristics. The command fails when it doesn't have a tty, ie when you connect with scp.

The solution is to protect the stty so that it runs only when an interactive session is present. There are a number of ways to do this; here are some examples for bash/sh type shells:


stty ... >/dev/null 2>&1

Works for me:

test -n "$PS1" && stty ...

Recommended elsewhere on SE:

# Check for a bash login shell
case $- in
  *i*) stty ... ;;
| improve this answer | |

I am not sure if it matters on OSX sshd implementation but on some systems, when you don't have a tty, the implied home directory with ~/ convention, may not expand and you may get some unexpected results. I know it is not a sure thing but please try with full path names, instead of ~/ construct.

| improve this answer | |
  • It seems that even providing a full path, the remote server does not recognize the location of the local directory and file and oddly offers a reference to being unable to locate the local directory and file ... giving a url that refers to the 'remote' root. Weird and frustrating. – user2217265 Apr 2 '13 at 1:13
  • Does not seem to work with absolute url. Remote server gives error essentially unable to locate the local directory and file to copy. – user2217265 Apr 2 '13 at 2:00
  • @user2217265 Could you please add the exact command and error message to your question? – n.st May 11 '14 at 1:27

This happens to me when my .bash_profile tries to load. I added

[ -z "${PS1}" ] && return;

At the top and it fixed it

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.