I was recently working on a Perl script that would SSH to another server and run a sudo command on the remote server that was failing. The error that was received is below.

Error: sudo: sorry, you must have a tty to run sudo

The reason for this is an update along the way with sudo locked it down further by adding the below line to /etc/sudoers configuration file.

Defaults requiretty

To allow a remote script to login and run a command via sudo simply comment out that line as shown below.

# Commented out so remote script can login and run a command without a tty
# Defaults requiretty

I would suggest making a comment in the sudoers file along with the actual script that is running just in case there is another systems administrator that is tasked with working on this server at a later date. Now when your script runs it will not throw that error and should be able to run the remote command that was initially required.

DeliciousStumbleUponDiggTwitterFacebookRedditLinkedInEmail
Tags: , , , , , , ,
44 Responses to “sudo: sorry, you must have a tty to run sudo”
  1. panchicore says:

    thanks. it works for me.

    [Reply]

    alex Reply:

    Cool. Glad it helped.

    [Reply]

  2. Jay says:

    Instead of commenting it out for everybody, you can just turn it off for certain users (or user groups)

    Defaults:alex !requiretty

    [Reply]

    alex Reply:

    Hello Jay,

    Great advice. I wasn’t aware of that syntax. Thanks for posting a response man!~

    [Reply]

  3. Vivek Singh says:

    Great Help!!!!!!!!!

    [Reply]

    alex Reply:

    Thanks for the feedback!

    [Reply]

  4. Nathan Hays says:

    The “-t” switch on the ssh command will allocate a pseudo tty. You won’t nned to change yor sudoers file.

    [Reply]

    alex Reply:

    Hello Nathan,

    Thanks for the addition.

    [Reply]

  5. Neel says:

    Is there a way to include “-t” option from perl script?
    From command line, we can say “ssh -t user@host”

    As of now, my code is as follows:

    my $ssh = Net::SSH::Perl->new($host);
    $ssh->login($user, $password);
    my($stdout1, $err, $ext1) = $ssh->cmd(“sudo su – geneindex”, $password);

    [Reply]

    alex Reply:

    Hello Neel,

    Sorry for the delayed response. Below is the response from a friend of mine that knows way more Perl than I.

    net::ssh takes the ‘use_pty’ option, which should have the same effect as -t for the cli command

    http://search.cpan.org/dist/Net-SSH-Perl/lib/Net/SSH/Perl.pm

    Hope that helps.

    [Reply]

  6. nate says:

    Thanks mate

    [Reply]

    alex Reply:

    Hello nate,

    No problem. Thanks for leaving feedback.

    Thanks.
    alex

    [Reply]

  7. Давыд says:

    Я бы кое-чего добавил конечно, но по сути сказано все.

    [Reply]

  8. мepтвeц says:

    Очень хороший и актуальный блог! Стабильный житель моего RSS ридера :)

    [Reply]

    alex Reply:

    Hello мepтвeц,

    Thanks for the compliment. Glad you use the RSS functionality to read the blog and hope you continue to find it useful.

    Thanks.
    alex

    [Reply]

  9. Thomas says:

    Or you can leave “Defaults requiretty”.
    I found it’s more secure to add this only for exactly that user like:
    “Defaults:username !requiretty”

    Thomas

    [Reply]

    alex Reply:

    Hello Thomas,

    Thanks for the response. I agree if you only required specific usernames such as the situation I mention in the article above that your way is much more secure and the right way to do it. I was unaware that you could open it up on a username basis as you have explained so I really appreciate the feedback. Responses like this are definitely part of the reason that I post articles like this so I can not only provide solutions to others but also hopefully find better solutions for myself.

    Thanks again for taking the time to leave feedback and provide a better solution for opening up the TTY on a per user basis.

    Thanks.
    alex

    [Reply]

  10. Thomas says:

    Thanks for your first post and also this feedback.
    Thomas

    [Reply]

    alex Reply:

    Hello Thomas,

    No problem at all. I really appreciate people sharing alternative ways to accomplish things. We can’t all know everything so it is definitely nice to learn new things. Look forward to your feedback on future posts.

    Thanks.
    alex

    [Reply]

  11. seo tools says:

    While I don’t have much else to add to this post, I am certainly grateful that the author took the time to talk about this. I agree with most of what was talked about, and look forward to learning some more from you. Thank you.

    [Reply]

    alex Reply:

    Hello SEO Tools,

    Thanks for taking the time to leave feedback relating to the sudo article.

    Thanks.
    alex

    [Reply]

  12. Rick says:

    solved my problem!

    [Reply]

    alex Reply:

    Hello Rick,

    Good to hear. Thanks for taking the time to leave feedback.

    Thanks.
    alex

    [Reply]

  13. Daniel says:

    Thanks for this. I managed to waste quite a bit of time with this problem until I wised up and took a look at the apache log file and saw what was going wrong. Shame this is not mentioned anywhere in the sudo or visudo man pages.

    Daniel

    [Reply]

    alex Reply:

    Hello Daniel,

    No problem. Thanks for taking the time to leave feedback.

    Thanks.
    alex

    [Reply]

  14. Wilfred says:

    That’s a good article about sudo: sorry, you must have a tty to run sudo. Thanks for the info.

    [Reply]

    alex Reply:

    Hello Wilfred,

    No problem at all. Thanks for taking the time to leave feedback.

    Thanks.
    alex

    [Reply]

  15. dofollow blogs says:

    I was wondering about sudo: sorry, you must have a tty to run sudo. I was looking for this information for a long time. Thanks for this post!

    [Reply]

    alex Reply:

    Hello dofollow,

    No problemo. Thank you for leaving feedback and letting us know that you found the article helpful.

    Thanks.
    alex

    [Reply]

  16. Joe says:

    You can also make security admins happier by limiting the scope of your removal of restrictions by specifying the user who can issue a command with no tty. Rather than removing the default for everyone as mentioned in this post, add the user name as follows

    Defaults:user1 !requiretty

    The ‘!’ means ‘not’ in this situation, and of course ‘user1′ should be your actual user name.

    Joe

    [Reply]

    alex Reply:

    Hello Joe,

    Yeah definitely fair enough I totally agree. The goal of the article (not saying its perrfect :) ) is to accomplish the goal in the easiest manner and without going into to many details with people the above works. If users read these comments I definitely agree with Joe. Thanks for taking the time to leave feedback.

    Thanks.
    alex

    [Reply]

  17. Guillermo says:

    Thanks for your post. I run into this problem while using capistrano.

    [Reply]

    alex Reply:

    Hello Guillermo,

    No problem. Thanks for taking the time to leave feedback.

    Thanks.
    alex

    [Reply]

  18. tuni says:

    Thanks

    [Reply]

    alex Reply:

    Hello tuni,

    No problem at all. Thank you for leaving feedback.

    Thanks.
    alex

    [Reply]

  19. Geoff says:

    Thanks, but it should also be mentioned that the issue of sending passwords in the clear was enabled by that edit of /etc/sudoers.

    SSH I had forgotten has an option that makes this change unnecessary. Just use:

    ssh -t

    instead.

    [Reply]

    alex Reply:

    Hello Geoff,

    Thanks for following up! I wasn’t aware of the -t switch with SSH. That will definitely come in handy in the future.

    Could you explain more how the edit of the sudoers file causes passwords to be sent in the clear? I want to make sure I understand the details there.

    Thanks.
    alex

    [Reply]

  20. RevRagnarok says:

    Yes, “ssh -t” is the proper solution if you are doing an interactive shell with sudo.

    I ran into this today and did some research. You will note that the warning in RHEL5 does NOT say the password will be SENT clear but SHOWN clear. Basically, when you type your password, it is encrypted on the link but would be shown on the screen because the non-TTY connection wouldn’t be able to do special controls like suppress display of your keystrokes. So it’s confusing but makes sense in the long run. If you have “NOPASSWD” in your sudoers file, it doesn’t matter anyway.

    [Reply]

  21. wcarlson says:

    Note: this means cron jobs that say use sudo on the localbox ONLY are not impacted (as no one is typing a password anyway). For example, a cron job that runs vgs to check volume group space.

    sudo -u blah vgs is safer than making a binary suid root, IMO.

    [Reply]

    alex Reply:

    Hello wcarlson,

    Thanks for taking the time to leave feedback.

    Thanks.
    alex

    [Reply]

  22. meanguy says:

    instead of tinkering with the requiretty setting (which can result in printing the root password to the screen) use

    $ ssh -t …

    [Reply]

    alex Reply:

    Hello meanguy,

    Thanks for the opinion. It has been suggested numerous times in the comments. Stay mean!

    Thanks.
    alex

    [Reply]

  23. esites says:

    Just to say thanks

    [Reply]

  24.  
Leave a Reply

*Type the letter/number combination in the abvoe field before clicking submit.

*