I use PuTTY sessions to talk to an embedded device running QNX 6.4.1 using SSH over TCP/IP.
Today, one of my systems mysteriously won't allow me to have more than one PuTTY session open at a time. If I try to start a second session, I can authenticate with user name and password, but the sign on banner prints out with an extra blank line between each line and messes with my ability to hit enter. I can do nothing that looks remotely valid except Control-C or close the PuTTY window.
I suspected the text file that contains the banner had bad line
endings, but it does not.
I suspected terminal setting issues, but if I have one session open it
works. With no changes to settings, just trying to open a second session it
does not.
I wondered if the .profile was getting mangled, but that doesn't
seem to be the case either.
Now I'm down to "perhaps ssh is messed up and rebooting would fix
it?" But I am hesitant to reboot it because if we lose TCP/IP
connection to it, it's several hours worth of work (physical labor)
to restore.
Any thoughts about what is going wrong and how I can fix it?
I'm connecting using PuTTY 0.62 from 64-bit Windows 7 to QNX 6.4.1. The openssh/openssl version is modern.
UPDATE
The issue came back a few days later. Using Guntram Blohm's suggestion below, I was able to at least get past the "Press enter once you've read the banner" screen. I then ran stty sane ctrl-j as he recommended. Here is the output of stty:
Bad after I had run stty sane ctrl-j (And hand reformatted it to be readable)
Name: /dev/ttyp1
Type: pseudo
Opens: 3
+raw +echo
+osflow
intr=^C quit=^\ erase=^? kill=^U eof=^D start=^Q stop=^S susp=^Z
lnext=^V min=01 time=00 pr1=^[ pr2=5B left=44 right=43 up=41
down=42 ins=40 del=50 home=48 end=59
I then opened another PuTTY session immediately after this and it worked properly. This is confusing me how it works sometimes and doesn't work others. How can that happen? What is different?
Good
Name: /dev/ttyp2
Type: pseudo
Opens: 2
+edit
+osflow
intr=^C quit=^\ erase=^? kill=^U eof=^D start=^Q stop=^S susp=^Z
lnext=^V min=01 time=00 pr1=^[ pr2=5B left=44 right=43 up=41
down=42 ins=40 del=50 home=48 end=59
So right now I have a good PuTTY terminal open, and a bad one. What else can I do to isolate this issue?
It's probably another process that uses the pseudo-terminal, puts it in a special state, then crashes without restoring the state. vi comes to mind, or maybe a file upload/download program. These programs change the terminal mode to read each character indicidually, instead of line by line, and tweak a few other things as well. Normally, logging out/back in SHOULD fix that, but i'm not sure QNX handles it correctly.
One thing you could do to copy the parameters of a working terminal to the messed up one is stty -g on the good one, then paste that output to the command line of the bad one. Like this (on Linux, i don't have a QNX at the moment):
(on the good terminal)
gbl#bermuda$ stty -g
500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
(on the bad one)
gbl#bermuda$ stty 500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0
These terminal modes are kept per pseudo tty device, that's why your /dev/ttyp1 can be messed up, while the /dev/ttyp2 that's allocated for the next ssh connection is ok.
Related
I was trying to display the time to see if I had the timezone correct... instead of the command 'clock'(which I know is not right now) I used 'vlock'. This locked my terminal while I was setting up archlinux. Now I am stuck on a screen that says
"The tty1 is now locked by root. Use Alt-function keys to switch to other virtual consoles.
Password:"
And I do not remember setting up a password so I do not know how I could guess correctly. Is there a way to undo the vlock? or should I just start a new archlinux VM?
I currently am using Cmder (which is effectively conemu) to SSH into a university cluster from my Windows machine. I want to enable x-forwarding, and I have Xming installed. I followed the instructions here, which I swear I've used before but doesn't seem to work right now. Specifically, I type
DISPLAY=localhost:0.0;export DISPLAY;
once I open up a Cmder terminal (with Xming already loaded), but the error I get back is
Error: cannot open display: localhost:0.0
despite Xming saying it is Xming server:0.0. Any suggestions? I should add that the x-forwarding works perfectly fine with MobaXterm, but I'd prefer to stick with Cmder.
The issue was that I was setting the display variable on the client server, not the host computer. On my Windows machine, I opened Xming and then did
set DISPLAY=127.0.0.1:0.
Afterwards, I SSH'd into the client server via
ssh -X myname#address.
Now everything works as intended.
I have exactly the same problem. However, I have observed that if I open up a Putty session with x11 forwarding set, then add the display number to my ConEmu session that is ssh'd into the Linux box, then x11 works from ConEmu. Weird.
It is an inconvenient workaround at best.
I made it work for me.
Even so Xming was telling me "localhost:0.0", after connecting to the my server (using the "-x" ssh's option) I rather did :
DISPLAY=:10.0;export DISPLAY;
The following worked for me:
export DISPLAY=127.0.0.1:0
ssh -XC <hostname>
My java program uses ssh/sftp for transferring files into linux machines (obviously...), and my library for doing so is JSch (though it's not to blame).
Now, some of these linux machines, have shell login startup scripts, which tragically causes the ssh/sftp connection to fail, with the following message:
Received message too long 1349281116
After briefly reading about it, it's clearly a known ssh design issue (not a bug - see here). And all suggested solutions are on ssh-server side (i.e. disable scripts which output messages during shell login).
My question - is there on option to avoid this issue on client side?
Check your .bashrc and .bash_profile on the server, remove anything that can echo. For now, comment the lines out.
Try again. You should not be seeing this message again.
put following into the top of file ~/.bashrc on username of id on remote machine
# If not running interactively, don't do anything just return early from .bashrc
[[ $- == *i* ]] || return
this will just exit early from the .bashrc instead of sourcing entire file which you do not want when performing a scp or sftp onto that target remote machine ... depending on shell of that remote username, make this edit on ~/.bashrc
or ~/.bash_profile or ~/.profile or similar
I got that error too, during and sftp get call in a bash script.
And according to the TO's error message, which was similar to mine, it looks like the -B option of the sftp command was set. Although a buffer size of 1349281116 bytes is "a bit" too high.
In my case I also did set the buffer size explicitly (with "good intentions"), which cause the same error message, followed by my set value.
Removing the forced value and letting sftp run with the default of 32K solved the problem to me.
-B buffer_size
Specify the size of the buffer that sftp uses when transferring
files. Larger buffers require fewer round trips at the cost of
higher memory consumption. The default is 32768 bytes.
In case it confirms to be the same issue, that whould suite as client side solution.
NOTE: I had to fix .bashrc output on the remote hosts, not the host that's issuing the scp or sftp command.
Here's a quick-n'-dirty solution, but it seems to work - also on binary files. All credits goes to uvgroovy.
Given file 'some-file.txt', just do:
cat some-file.txt | ssh root:1.1.1.1 /bin/bash -c "cat > /root/some-new-file.txt"
Still, if anyone know a sftp/scp built-in way to do so on client side, it'll be great.
I've got problem with my Go server.
When I'm connected to my NAS via SSH and do ./gogs web, the server is starting. But when I close the SSH connection, the server is stopped.
How I can start my Go server permanently?
You have scripts in gogs allowing you to launch the server as a daemon:
scripts/init/debian/gogs (recently fixed with issue 519)
scripts/init/centos/gogs
That would allow the process to remain while the session is closed.
You have other options in issues 172.
This is not a Go-specifioc problem, what is happening is that the Go program is still attached to your terminal and when you log out, the kernel will trigger a SIGHUP to every binary still connected to that terminal session.
Your best option is probably to use nohup ./gogs web.
Second-best option would be to rewrite main, so that it intercepts and handles SIGHUP, stopping it from killing your program. However, doing so requires handling quite a few things properly (you really should close stdin, stdout and stderr; make sure all your logging is done through the log library, ...)
I've got a Windows 7 machine setup with vagrant/virtualBox - each morning when I try to access my development site it always a 'Unable to connect' error message in my Firefox browser.
Even though I have booted the machine using the 'vagrant up' command for some reason it only seems to be accessible via the browser once I have done the 'vagrant provision' command. This is obviously annoying as it starts doing stuff from scratch.. eg installing my mysql database again.
Can anyone provide any light into this, and why it seems to fail to connect all the time - as this provision command is only a temporary fix as i'll need to amend the DB everytime which is only feasible in the short term.
Might just be my own setup - but I noticed nginx was restarting so have to restart this each time