Hot answers tagged tty
Try using the -t option to ssh ssh -t firstname.lastname@example.org screen "tail -f /var/log/messages" From man ssh -t Force pseudo-tty allocation. This can be used to execute arbi- trary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, ...
Try one of these: stty sane or reset If both don't work, or your terminal is so messed up that you can't even enter commands, then it is best to close the terminal and start a new one. Note that stty sane is defined by POSIX whereas reset is not. That means on some systems there might not be a reset or it might do something completely different, like ...
You can try using the reset command.
You can use: ssh root@host screen -m -d "tail -f /var/log/messages" That starts a detached screen with a command running on it. -m causes screen to ignore the $STY environment variable. With "screen -m" creation of a new session is enforced, regardless whether screen is called from within another screen session or ...
The primary difference is the concept of interactivity. It's similar to running commands locally inside of a script, vs. typing them out yourself. It's different in that a remote command must choose a default, and non-interactive is safest. (and usually most honest) STDIN If a PTY is allocated, applications can detect this and know that it's safe to ...
The reset command should work.
In sudoers config file, there is an option - requiretty - which will prevent you from running sudo without being logged as a real user. see sudoers(5) man page
You should set up key-based authentication for your users on the ssh server. Once you have key-based authentication configured, it's easy to set up the user's authorized_keys file to deny the user a tty using hte "no-pty" option for the key. Look at the man page for sshd and go to the AUTHORIZED_KEYS FILE FORMAT section for the available options: ...
Use SSH keys and specify the command= parameter in the authorized_keys file of users who should only run some commands. In this command= parameter, pass a script which will check for the commands users can run.
The "requiretty" option may solve your problem. Why not just install the cron job under the the user that you are attempting to sudo to?
On most systems, you can look for files under /usr/share/terminfo. On some versions of Solaris that may be /usr/lib/terminfo instead. Some system will also have a termcap file, which may be in /etc. /usr/share, or occasionally /usr/share/misc; the terminal names in that are in lines matching ^[^\t].*|, and every name between |s is a valid terminal name. ...
Late answer, but this is what I do, I make an alias (let's call it t) that does this: ssh $MYSERVER -a -x -t screen -xRR -A -e^Zz -U -O This tells ssh to disable agent and X11 forwarding, and tells screen to attach to a running session, start a new one if needed, use ^Z as the breakout command, use UTF-8 and be smart about the terminal. All this means ...
Yes, they certainly can. From http://www.linuxakesson.net/programming/tty/index.php Run yes in an xterm, and you will see a lot of "y" lines swooshing past your eyes. Naturally, the yes process is able to generate "y" lines much faster than the xterm application is able to parse them, update its frame buffer, communicate with the X server in order to ...
sudo: Sorry, you must have a tty to run sudo Run visudo and add the following line to disable requiretty for your user: Defaults:username !requiretty
By putting the following in the ~/.bashrc file on my server, it starts a screen session the first time I log on to the server, or if one is already running, re-connects me to that session. I find this very handy: if [ -n "$SSH_CONNECTION" ] && [ -z "$SCREEN_EXIST" ]; then export SCREEN_EXIST=1 screen -DRi fi
What does ls -la /dev/tty show? Is it both world-readable and world-writeable? $ ls -la /dev/tty crw-rw-rw- 1 root tty 5, 0 Aug 23 20:58 /dev/tty $ That is what you should see. If not, that's your problem.
Your SSH key is corrupted. Connect with password authentication or the console and regenerate your SSH keys (or restore from a backup).
I had this same issue with a Rackspace-hosted server that I recently upgraded to Ubuntu 12.04 LTS. My /var/log/auth.log file was getting flooded with May 13 12:50:40 foo getty: /dev/tty2: cannot open as standard input: No such device May 13 12:50:51 foo getty: /dev/tty3: cannot open as standard input: No such device May 13 12:50:51 foo ...
fgconsole is what you are looking for http://linux.die.net/man/1/fgconsole
The way to speed up your compile if you are afraid of this is: make >&/tmp/log.out & tail -f log.out
You're logging in just fine - whatever shell you're starting is exiting immediately. Boot to single user mode or a rescue CD and chroot into your installed system. First, check your startup scripts (profile, bashrc and the like). Make sure they're not doing anything that would exit immediately. Can you even chroot? If you can't, that means it can't run ...
I've got the SSH keys Are these keys setup under the root account? Host key verification failed. The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established. RSA key fingerprint is . Your program is not writing out to the known_hosts file. The host you are trying to connect to hasn't been used from the account that the java ...
Try hitting enter when it does that. It seems to help at least some of the time.
How about hiring a freelancer you can trust? This kind of spying takes a lot of time/effort, and you're not even guaranteed to see when he's doing something bad.
This isn't an answer to your specific query, but it's a solution to your specific issue. Rather than using sudo, do what other munin plugins do, override the user which runs the specific plugin to be root. More information here. You add a section like this, [<plugin name>] user <user> group <group> to munin-node in the plugin-conf.d ...
Would it be sufficient to use screen or tmux in split mode? command sequence for screen (default keymaps): screen - tail -f <logfile> ctrl-a shift-s ctrl-a <tab> ctrl-a c <send commands via shell> command sequence for tmux (default keymaps): tmux tail -f <logfile> ctrl-b " <send commands via shell>
You can replace one or more of your vty configs with, instead of a local shell, a telnet or SSH command to your server. I recommend not putting your password into the init config for it for obvious reasons. When you switch to that vty, it will connect; perhaps requiring a keystroke to re-attempt if it's sitting at a timed-out connection. More like a ...
I solved this problem using pyserial library of python. http://pyserial.sourceforge.net/
The answer to your question is to edit /etc/sudoers and add Defaults:tomcat7 !requiretty, like stated in No TTY present when running commands over SSH in here-document and sudoers: how to disable requiretty per user
Perhaps you had a major glibc change or something that's affecting login. Did you reboot following your yum update or at least see what was updated in /var/log/yum.log? The latter will tell you which packages were modified/updated. You can verify the installed /bin/login binary with: # rpm -qf /bin/login util-linux-2.13-0.59.el5 # rpm -vV util-linux | grep ...
Only top voted, non community-wiki answers of a minimum length are eligible