Tag Info

Hot answers tagged

44

Try using the -t option to ssh ssh -t root@my.machine 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, ...


44

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


14

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


8

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


5

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


4

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


3

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


3

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


2

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


2

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


2

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


1

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


1

This could be due to a built in protection from the auditing system. Here is a relevant quote from somebody debugging your same situation. It appears as though non-root users are prevented from sending the USER_TTY records. Instead commands will be written out either when bash exits or the collection buffer fills up. You should be able to find the ...


1

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


1

Look to see if those devices exist: ls -l /dev/tty[2-6] If they don't then do this: cd /dev MAKEDEV -n console That command name is in all caps. The -n switch (for "no action") will show you the actions MAKEDEV will take. If you are satisfied with what it proposes, then change the -n to -v (for "verbose") and run it again.


1

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[1796]: /dev/tty2: cannot open as standard input: No such device May 13 12:50:51 foo getty[1798]: /dev/tty3: cannot open as standard input: No such device May 13 12:50:51 foo ...


1

Sounds like you do not have a fully wired cable in there somewhere. If reversing the cable changes things, the CD might be clipped on one side or cross wired. If you are using the typical Cisco RJ45 to DB9 in the cable path, that will drop CD. (Very annoying when working with full PCs or single board computers that care about CD.)


1

This seems to be an issue within libvirt or Qemu. I have not had much opportunity to delve into which specifically is creating the issue. There does seem to be a ticket open regarding it with RedHat, however it was opened back in March and is still marked new. This is likely not a high priority issue. REF: ...


1

your best bet (and probably most reliable) is to give the user correct sudo access to the commands needed and with the NOPASSWD flag eg if your user running the script is bob, to reload nginx via sudo without a password the syntax of /etc/sudoers would be: bob ALL= NOPASSWD: /etc/init.d/nginx reload your script above would effectively be changed to: ...



Only top voted, non community-wiki answers of a minimum length are eligible