How to keep telnet connection alive from client side - linux

I have a device as a telnet server but drops the connection if no packet is received in 60 seconds, for some reason this behavior cannot be changed. Putty has a feature to send null packets to the server periodically to keep the session alive, which works fine for me. But some times I have to telnet to the device from linux terminal, where putty is not available. So I wonder if it's possible to periodically send null packets with the linux telnet client, or any other way to keep the session alive, or other command line telnet client that could do this.

This is not a perfect solution, but might suffice. Wrap the telnet within an expect script that detects lack of input. It sends the escape sequence control-] to the telnet client to get the command prompt telnet>, and issues the command send nop (no-operation). I assume this is enough to keep the connection alive. If not there are other commands to try.
#!/usr/bin/expect
spawn telnet localhost
expect "ogin: "
send "username\r"
expect "assword:"
send "mypw\r"
expect {$ }
interact timeout 10 {
log_user 0; send "\x1d"; expect "telnet>" { send "send nop\r" };
expect "send nop\r\n"; log_user 1 }
Obviously, you need to edit this with the desired hostname, username, password, and expected command prompt. See man expect for the syntax.

With the command line telnet client that's not possible. You can enable frequent TCP keepalives globally: TCP Keepalive HOWTO. I don't know if this has any side-effects, but it seems like a viable workaround.
By the way, putty is available on Linux. You just need to have an X server on your machine to run it on a remote host (I assume you're ssh-ing into the Linux box where you do your telnet work). If you're on Windows, the Linux Subsystem for Windows together with an X server might do the trick. Cygwin also works for this.

Related

Somewhat convoluted ssh issue. Can ping, but not ssh, but only from on-site

I am trying to ssh into my server at work (CentOS) from my laptop (Ubuntu). When I am at home, I do it by running the following script on the server (I start it while I am physically at work):
ssh -R (port #):localhost:22 (name#home ip)
I do this because it doesn't accept connections from external IPs. Then, I can ssh into the specified port on my laptop, and it works fine.
However, when I am actually at work, I cant ssh to the server. The other people in my office can. They do this very simple command (only works while they are at work, since they need an IP from inside the system):
ssh (username)#(work ip)
And they are automatically logged in. When I do that, I get no response; no public key denial, no wrong username, no response at all. Eventually it times out. But I know the server has ssh running, because everyone else can do it.
Additionally, if I do this on my laptop, while at work:
ping (work ip)
I do get response packets, with no loss, almost no lag. But ssh doesn't work.
I can ssh to other places from my laptop, both while I am at home and at work. So my laptop is properly configured to ssh to things, it just doesn't reach the work server for some reason. I talked to the guy who set it up and he insists there is no whitelist; the only security from internal IPs (and I am physically on site, so I have an internal IP, so there should be no need to do the ssh -r like I do at home) is the private/public RSA key system, and I know the keys must be already set up, because it works when I do the ssh -R from home. Plus, if the keys were not set up, I would get a public key denial, instead of no response at all, right?
If I do ssh -vv, this is the last line before it times out:
debug1: Connecting to ccny6 [work ip] port 22.
I see other people have posted similar questions, but the responses they seem to generally be "is the server running the ssh service" etc, which I know it is as other people can ssh to do (as can I if I'm using the ssh -r tunnel), so none of those responses did me much good, unfortunately.
Summary: I can ssh to a server from OFF site via a ssh tunnel, but can't ssh to it while I am right next to it using direct ssh, even though I can ping it, and others can ssh to it.
The most possible reason for the same is your ISP. I too had this issue few months back. They had closed ssh ports. Ask them and get it released.
Just a confirmation, try to do ssh to other IP's as well. It wont work either if your ISP has blocked it.

IP tunnel over Linux serial default shell

This is a more constrained version of this question:
I have an embedded ARM device running a custom image with a Linux 3.10.0 kernel.
The only physical interface (no, USB, no Ethernet) is the default Linux shell which is connected one of the serial interfaces.
My question is: Is there any built-in or external tool that opens an IP tunnel over this connection?
I see some general issues:
The device is already use by Linux, so it must use stdin/out to communicate instead of accessing the device directly.
After starting the tunneling application, the application must wait for a tunnel client to connect because I need to close the serial connection on my computer and then start the tunnel client.
There should be a way to close the connection and go back to the normal shell
The actual requirement is, that I can access a REST interface that is running on the embedded device from a computer connected to the embedded device via serial cable.
This already works on devices with a physical Ethernet or Ethernet-over-USB but this device does not offer that.
[UPDATE]
As explained, socat is currently not available on our embedded device so as a first attempt, I used the following:
A Linux (Ubuntu) laptop with a physical serial interface
A Windows Laptop with a physical serial interface and cygwin+socat installed
Both connected via Null-modem cable
Note: I'm using a Windows laptop on one side because we will have the socat client running on Linux (unfortunately).
Direct STDIO Connection
Server
socat stdio file:/dev/ttyS0,b115200
Client
socat file:/dev/ttyS4,b115200 stdio
In cygwin, ttyS0 is COM1, ttyS4 in this case is COM5.
Using these, socat works like a little chat program. Why I type on one side is output on the other and vice-versa.
TCP Connection
The next step is to use a TCP connection.
Server
socat /dev/ttyS0,b115200,crtscts=1,raw,echo=0 tcp-connect:localhost:80
Client
socat -T2 file:/dev/ttyS4,b115200,crtscts=1,raw,echo=0 tcp-l:7777,reuseaddr
I specified the baud rate (115200), used raw transmission, no echo (The HTTP request would otherwise be sent back to the requester) using hardware flow control. Pus I had to use a timeout -T2 wich terminates the connection after 2s. Otherwise, curl does not terminate either and waits for more data.
When I use curl on the windows computer, it successfully transmits the request over serial connection and returns the complete HTTP response of the HTTP server on the Linux computer:
curl localhost:7777/index.html
However, it works only once. After the request is completed, both socatclient and server terminates.
Moreover, when I use a browser (Chorme), it uses g-zip encoding which most probably sends binary characters. And one of these characters will be a EOF character which again terminates socat before completing the request/response.
Then I tried to add fork to the server:
socat /dev/ttyS0,b115200,crtscts=1,raw,echo=0 tcp-connect:localhost:80,fork
This keeps the server alive, but curl returns a 400 Bad Request. So it seems as if the socat server initiated a request for each line or chunk since it does not understand HTTP.
IP Connection
Then I thought about going a layer below and using a TUN connection. However, this is not implemented on the Windows version of socat.
HTTP connection
Correct me if I'm wrong, but as far as I understand, socatdoes not provide a connection type that actually understands HTTP and is able to serialize it properly over a serial connection.
So, I couldn't find any stable way to start both client and server and run multiple HTTP requests over the serial connection.
On a normal linux, you could use socat.
This program allows you to connect several stream types (file, socket, tcp, udp, ...). In your case it would be tcp to file or more precisely a tcp socket at port xx to /dev/ttyUSB1. You should launch socat on both sides to build a tunnel.
Edit 1:
Sorry I got also disappointed by socat. I can't find a solution that keeps my TCP listener active for multiple successive connections, but handles only one connection at a time.
My solution is a simple C# program that uses 4 threads:
1. wait for input on stdin e.g. exit command
2. the TCP listener
3. the TCP worker thread for a active connection
4. if TCP is open, it opens another thread for COM
Thread 3 reads from TCP and writes to COM and Tread 4 reads from COM and writes to TCP. If thread gets a TCP close event, it stops thread 4, which closes COMx, and exits it self. Now thread 2 can accept a new connection. If thread 1 reads exit on stdin, it passes a message to all threads to stop and shutdown.
Maybe you can implement such a short program in C with pthreads on your embedded system, which has no socat.
The EOF problem:
I tried to google for a program that escapes a special character or reencodes a data stream from ASCII to ANSI or base64 or whatever.... If you can find such a program or write it also in C you can pipe it in between
Server <=> reencode <=> socat <--serial--> socat <=> reencode <=> client
We've now solved the problem halfway using pppd. As it turns out, even Windows supports ppp. In contrast to socat, pppd actually uses a protocol that will have error detection included and it automatically creates network devices on the Linux and Windows system.
The only problem is, that pppd requires to have access to the serial device. There is no direct mode like the ppp tool provides.
We are now disabling the shell on demand, rebooting into IP-over-serial mode. When we are done, we reboot the system which automatically switch back to getty using the serial line.
The is not the prettiest solution but right now, it seems to work.

linux command to connect to another server using hostname and port number

what is the Linux command to connect to another server using host name and port number?
how to connect to another server using only host name and port number then check if an existing process is running? the only way i see it working is to log in to the server and run the PS command. but is there a way to do it without logging in directly to the other server and connect only with host name and port number and check the running process?
If you just want to try an arbitrary connection to a given host/port combination, you could try one nmap, telnet or nc (netcat).
Note that you can't necessarily determine whether or not a process is running remotely - it might be running on that port, but simply ignore anything it sees over the port. To really be sure, you will need to run ps or netstat or etc. via ssh or etc.
If you want to use SSH from e.g. a script or, more generally, without typing in login information, then you will want to use public key authentication. Ubuntu has some good documentation on how to set this up, and it's very much applicable to other distrobutions as well: https://help.ubuntu.com/community/SSH/OpenSSH/Keys.
If you have no access to the server you're trying to list processes on at all, then I'm afraid there isn't a way to list running processes remotely (besides remote tools like nmap and so on, as mentioned earlier - you can always probe public ports without authentication [although you might make people angry if you do this to servers you don't own]). This is a feature, not a problem.
telnet connects to most of services. With it you can ensure that port is open and see hello message (if any). Also nc is more low level.
eri#eri-macro ~ $ telnet smtp.yandex.ru 25
Trying 87.250.250.38...
Connected to smtp.yandex.ru.
Escape character is '^]'.
220 smtp16.mail.yandex.net ESMTP (Want to use Yandex.Mail for your domain? Visit http://pdd.yandex.ru)
helo
501 5.5.4 HELO requires domain address.
HELO ya.ru
250 smtp16.mail.yandex.net
MAILĀ FROM: <someusername#somecompany.ru>
502 5.5.2 Syntax error, command unrecognized.
If there is plain text protocol you cat talk with service by keyboard. If connection is secured try openssl.
openssl s_client -quiet -connect www.google.com:443
depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
verify error:num=20:unable to get local issuer certificate
verify return:0
GET /
<HTML><HEAD>
If protocol is not known you may see much of hieroglyphs or just Connected to ... message.
Try this :
ssh <YOUR_HOST_NAME> 'ps auxwww'
Like Dark Falcon said in the comments, you need a protocol to communicate with the server, a port alone is useless in this case.
By default on unix (and unix like) servers, ssh is the way to go.
Remote Shell with this command. Example is cat a file on the remote machine.
rsh host port 'cat remotefile' >> localfile
host and port self explainitory
remotefile: name of some file on the machine remote logging to in home directory
localfile: name of file cat information to.
Use monitoring software (like Nagios). It looks at your processes, sensors, load and thatever you configured to watch. It continuously stores log. It alerts you by email\sms\jabber if something fails. You can access it with browser or by HTTP API.

Notify me when a socket binds, like inotify does for files

I am interested in finding out when things SSH into my boxen to create a reverse tunnel. Currently I'm using a big hack - just lsof with a few lines of script. So my goal is to see when a socket calls bind() and, ideally, get the port it binds to (it's listening locally since it's a reverse tunnel) and the remote host that I would be connecting to. My lsof hack is basically fine, except I don't get instant notifications and it's rather... hacky :)
This is easy for files; once a file does just about anything, inotify can tell me in Linux. Of course, other OSs have a similar capability.
I'm considering simply tailing the SSHD logs and parsing the output, but my little "tunnel monitor" daemon needs to be able to figure out the state of the tunnels at any point in time, even if it hasn't been running the whole time SSHD has.
I have a pretty evil hack I've been considering as well. It's a script that invokes GDB on /usr/sbin/sshd, then sets a breakpoint on bind. Then it runs it with the options -d -p <listening port> -- Running a separate SSHD for these tunnels is fine. Then it waits for that breakpoint to get hit, and uses GDB's input to get the remote hosts's IP address and the local IP on which SSH is now listening. Again, that's text parsing and opens some other issues.
Is there a "good" way to do this?
I would use SystemTap for a problem like this. You can use it to probe the kernel to see when a bind is done by any process on the system. http://sourceware.org/systemtap/

Debug smtp connection

I am using the perl module Net::Smtp_auth to send a mail to myself using the web.de SMTP server on port 25 (no encryption). It works well my computer. But I would like to use the same script to send notification messages about finished jobs on a different machine where I don't have root privileges. On this machine I get a timeout for the connection. I wonder in which way the connection is blocked, what might be the reason to block it (prevent spamers?) and if there might be a way to circumvent the problem. I have some linux tools available but no nmap.
Might the connection be influenced by proxy settings and, if yes, how do I tell it to SMTP_auth?
The perl script is basically the SMTP_auth example from cpan. But I do not expect that it is relevant here:
#!/usr/bin/perl -w
use Net::SMTP_auth;
$message=$ARGV[0];
$smtp = Net::SMTP_auth->new('smtp.web.de') or die "Failed to open SMTP connection: $!";
$smtp->auth('CRAM-MD5', 'adress', 'password');
$smtp->mail('adress#web.de');
$smtp->to('adress#web.de');
$smtp->data();
$smtp->datasend("To: adress\#web.de\n");
$smtp->datasend("From: adress\#web.de\n");
$smtp->datasend("\n");
$smtp->datasend("$message\n");
$smtp->dataend();
$smtp->quit;
If the other machines are in a different network than your home machine, it may well be that the ISP there is blocking outgoing port 25 to anything but their own SMTP servers, as that is a common spam-mitigation technique. The established convention is that for outgoing mail across networks, one should use port 587 (the SMTP submission-only port) instead.
An easy way to verify if the problem is your program or not is to try to telnet to that host and port. If telnet doesn't connect but other services do, your ISP is filtering port 25.

Resources