Linux telnet connection refused

Почему маршрутизатор отказывается пустить вас телнетом

Вступление
С оборудованием Cisco я работаю уже несколько лет, но с подобной проблемой столкнулся впервые. Хотя может и не впервые :). Точно сказать не могу, так как всякого рода траблов и непоняток было много, из-за того что я настраивал в работу и изучал их одновременно. Но раньше скорее всего все решалось обычным хардрезетом, теперь же я разобрался в чем дело.

Что было поводом?
В один прекрасный день мне понадобилось зайти удаленно на один из роутеров Cisco, чтобы посмотреть вывод sh ver. Обычно я захожу со своей машины с OS Windows посредством Putty. Как обычно окно терминала открылось, и…, не выдав никакой текстовой информации с велкомом и приглашением к логину, сразу же закрылось без объяснения причин.

Попробовал с линуксового сервера:

]$ telnet 10.15.xxx.yy
Trying 10.15.xxx.yy.
telnet: connect to address 10.15.xxx.yy: Connection refused
telnet: Unable to connect to remote host: Connection refused

Попробовав еще несколько раз с тем же результатом с других хостов я решил немного
попинать головой стену подумать 🙂
И вот что обнаружилось и придумалось.

Так как фаервола и ACL от меня в сторону роутера не было, да и я заходил на роутер перед этим много раз на прошлой неделе, настраивая тоннель, то я сделал вывод, что закончились свободные vty line. Конечно, дошел к этому выводу я не так быстро и сразу, были разные предположения, но помогло то, что глюков в циске я еще не встречал, роутер по информации маршрутизации и cdp работал, в чудеса особо не верю, заходил на роутер буквально пару дней назад и еще помню примерно конфиг, плюс на днях читал блог одного цисковода, где он как раз тюннинговал эти самые vty line.

Что было сделано?
На прошлой неделе я настраивал на этом роутере (к слову сказать Cisco 1841) тоннель через партнерские сети к другому такому же роутеру. Что бы окно терминала не закрывалось из-за бездействия при выводе дебага, в настройках line vty я установил параметр exec-timeout 0 0 (время бездействия в 0 минут 0 секунд, то есть сессия будет висеть практически вечно).
В процессе настройки несколько раз выходил нештатно, то есть просто закрывал окно терминала. В итоге все мои telnet-сессии остались открытыми и занятыми и когда я попытался очередной раз зателнетится на роутер — меня не пустило.
Повезло только то, что был еще открыт доступ по http протоколу и это помогло диагностировать и решить проблему.

Что нужно сделать ?

Нужно посмотреть сводный статус TCP-соединений:

cisco#show tcp brief
TCB Local Address Foreign Address (state)
8173B78C 10.15.xxx.yy.23 10.15.aa.bb.2530 ESTAB
.
80CCEB24 10.15.xxx.yy.23 10.15.aa.bb.4427 ESTAB

Первая колонка — это TCB адрес (Transmission Control Block адрес установленого TCP-соединения). По аналогии с *nix, можно сказать что это PID процесса, который можно убить:

router#clear tcp tcb 8173B78C
[confirm]

для подтверждения нажав «y» мы убиваем данную сессию.

Таким образом, сняв TCP-сессии, я освободил vty линии и смог зайти телнетом на роутер.

Хочу заметить еще, что более подробно о TCP-соединении можно узнать, если ввести команду:

show tcp tcb [TCB address]

router#show tcp tcb 80CCF254
Connection state is ESTAB, I/O status: 1, unread input bytes: 1
Local host: 10.15.xxx.yy, Local port: 23
Foreign host: 10.15.aa.bb, Foreign port: 1840

Enqueued packets for retransmit: 1, input: 0 mis-ordered: 0 (0 bytes)

Event Timers (current time is 0x374828A8):
Timer Starts Wakeups Next
Retrans 123 7 0x374829CB
TimeWait 0 0 0x0
AckHold 128 11 0x0
SendWnd 0 0 0x0
KeepAlive 0 0 0x0
GiveUp 0 0 0x0
PmtuAger 0 0 0x0
DeadWait 0 0 0x0

iss: 2866020113 snduna: 2866027408 sndnxt: 2866027946 sndwnd: 65097
irs: 672352072 rcvnxt: 672352285 rcvwnd: 3916 delrcvwnd: 212

SRTT: 302 ms, RTTO: 319 ms, RTV: 17 ms, KRTT: 0 ms
minRTT: 156 ms, maxRTT: 564 ms, ACK hold: 200 ms
Flags: passive open, higher precedence, retransmission timeout

Datagrams (max data segment is 536 bytes):
Rcvd: 248 (out of order: 0), with data: 137, total data bytes: 212
Sent: 166 (retransmit: 7, fastretransmit: 0), with data: 154, total data bytes: 8368

Источник

Telnet [Unable to connect to remote host: Connection refused]

I was trying to create a telnet connection between Ubuntu and Guest OS (Kali). But the problem «Unable to connect to remote host: Connection refused» occurs in both Ubuntu terminal and Guest OS (Kali) Terminal. I configured Guest OS’s ip settings as follows and I can send ping packets perfectly from both side.

According to ping packets sent and received, it seems there is no problem about connection line between these two system. But when I try to enter

the terminal returns «Unable to connect to remote host: Connection refused» error. How can I handle this problem?

4 Answers 4

0.Configure Guest OS via Virtualbox as follows.

1.Install telnet use this command in main OS terminal:

2.Edit /etc/inetd.conf in main OS using your favourite file editor with root permission,add this line:

3.Edit /etc/xinetd.conf in main OS,make its content look like following:

4.Use this command to start telnet server in main OS:

That was all. By the way, this configuration will affect just main OS which you use instead of Guest OS. That is, you can create a telnet connection just from Guest OS’s terminal to main OS, not from main OS to Guest OS. Because, telnet server is in main OS. To be able to do two way telnet communication, you should repeat the steps above in Guest OS’s terminal.

Источник

How to fix “telnet: connection refused by remote host” error?

Telnet errors are sometimes hard to decode.

One such error is telnet: connection refused by remote host.

At Bobcares, we help server owners resolve these errors as part of our Dedicated Support Services.

Today, let’s discuss the top 4 reasons for this error and how we fix them.

telnet connection refused by remote host – Causes and Fixes

Here are the major reasons for the error “telnet: connection refused by remote host” and how our Dedicated Engineers fix them.

1) Telnet service not running

One of the most likely reasons is that the telnet service isn’t installed on the machine the user is trying to connect.

Telnetd is the daemon that supports Telnet protocol. So, for the telnet communication to happen smoothly, telnet service must be installed at the destination. Otherwise, there’s no daemon to answer the telnet connection from source and results in this error.

And, customers see the below error when they use telnet to connect to localhost or any other server.

How we fix?

In such cases, our Support Engineers ask customers to check if Telnet is installed on the machine they are trying to connect. Otherwise, it must first be installed. For example, on Linux Ubuntu servers, we install telnet tool using the below command.

Further, we make sure that this service is started and running fine in the server. We usually start the telnet service using the below command.

Moreover, we ensure that the machine that we are connecting to doesn’t block the standard telnet port 23. If so, we’ll open the port in the server firewall. For example, we allow the telnet port in UFW using the below command.

However, Telnet is highly insecure as the communication is not encrypted. In other words, your passwords and all other data is transferred as plain text which is insecure. So, our Support Experts always recommend customers use Secure Shell(SSH) instead of telnet. And, only use telnet unless it’s absolutely necessary.

2) Telnet disabled in configuration file

Another common possibility for the error telnet: connection refused by remote host is telnet service disabled in it’s configuration file.

Xinetd service controls telnet in Linux. There’s a parameter disable in xinetd configuration file “/etc/xinetd.d/telnet”. This decides whether telnet service should be disabled in the server or not. We’ve seen instances where users forget to enable this parameter which can cause problems.

How we fix?

Our Support Experts ensure that the telnet service is enabled on the destination server by changing the parameter disable=no. Most importantly, we take a backup of this file before making changes. Also, we make sure to restart the xinetd service to reflect these changes.

[Need help in installing telnet service on your server? We can help you here.]

3) Firewall restrictions

Similarly, this error may occur when the firewall in between is rejecting the connections.

For example, customers see the below error when firewall is restricting the connections.

This error means that firewall is blocking connections to the specified port on the remote host. The firewall can be at the remote host or at the intermediate level.

How we fix?

In such cases, our Support Engineers get the traceroute results from the client side to the destination end. This gives us an idea where the connection is getting interrupted.

If the connection is interrupted at the remote host, then we make sure that the required port is opened in the server firewall. Moreover, we ensure that the customer’s IP address isn’t blocked at the remote host. Alternatively, if the connection drops at the intermediate level, then most probably the issue lies at the ISP end. In such cases, customers need to contact the ISP end to fix the problem.

4) Service not running

Another possible reason for this error is that there is no service listening on the connected port.

For example, server owners usually set the HTTP port to 80. Consider customers trying to connect to port 80 using telnet, but the HTTP service isn’t running on the server. So, users receive the below error.

How we fix?

In such cases, our Support Engineers first verify whether the service is enabled and running on the server. For example, on Linux servers, we check the status of http service as below.

Further, we verify the port that this service is listening. For example, we use the netstat command to verify the port on which the http service listens. In addition to that, this command also shows which IP address it’s actually bound to.

So, if the customer uses wrong port or IP address, we’ll update them to use the correct details for connecting.

Conclusion

In short, telnet: connection refused by remote host is a common error raised by the customers. This can occur due to firewall restrictions, disabled telnet service, etc. Today, we’ve discussed the top 4 reasons for this error and how our Dedicated Support Engineers fix them.

Источник

telnet: Unable to connect to remote host: Connection refused when trying to connect running docker image

I am having ubuntu 18.04 running on a server. I am got a JasperServer image running on docker in it. I am trying to access it from my system. But it throws the following error:

Here is the output for sudo docker ps -a

if I telnet on localhost, it connects and then connection closes which means it is running well. Here is the output when I telnet it from localhost:

Here is the docker-compose file

Here is the output for sudo docker logs container_id_for_jasper

I can telnet other ports from my local machine but having an issue with this one. Any ideas? thanks

keeping in the view of bullet 2 from answers, I executed the below command and found that 9095 is allocated by the server. Any ideas, please?

2 Answers 2

To people who got there and didn’t find solution:

Make sure your web server is listening on 0.0.0.0 to listen ALL interfaces, including docker bridge to outer network

Based on your question, you know:

• Docker container is running
• Docker container is listening to port 9095
• telnet from Linux server to docker container is working
• telnet from other client somewhere in Internet to docker container is NOT working

I guess your Ubuntu server is not accepting incoming requests from Internet on port 9095. There can be many reasons for that:

• Your server has firewall settings, which block connection
• Your server did not publish port 9095 to Internet
• Your client has no Internet access, when using port 9095

So I would investigate these aspects.
The docker part seems to be ok, because telnet to localhost is working.

Источник

Basic troubleshooting with telnet and netcat

Image by Gerhild Klinkow @ Pixabay

In the early years of computing, telnet was used to connect to the command line on remote systems. SSH has replaced telnet for remote access needs, and these days when you hear about telnet , it is usually when somebody is using the client as a generic network troubleshooting tool.

That’s because, in troubleshooting sessions, sysadmins turn to telnet and netcat to test connectivity to service offerings.

Telnet

See what this process looks like for telnet :

Here is a breakdown of the parameters:

• -4 means to use IPV4. This flag is not necessary but it made my logs prettier.
• www.redhat.com is the hostname/IP address to connect to.
• 80 is the port to connect to.

More Linux resources

That Connected to www.redhat.com line states that the connection was successful. This result means that the server is operational and there is nothing on the network (or any client or server machine) blocking this connection from happening.

You can exit out of telnet by pressing Ctrl+] and then typing quit :

Here is an example of a failed connection in telnet :

Depending on how the remote network is configured, you may see a Connection refused message immediately, or you may have to wait a while to get the Connection timed out error. Alternatively, if telnet sits there for a few seconds without any output, it is usually safe to assume that the connection will time out, so you can stop the connection attempt by doing a Ctrl+C.

When you see errors like this, it means that any of the following things are wrong:

• The server daemon isn’t running.
• The server itself isn’t up.
• A firewall rule is blocking the connection.
• There is no network route to the destination.

Netcat

Now, look at this same process with Netcat ( ncat on Red Hat Enterprise Linux 8 and related distributions, abbreviated nc ). Here is an example of a successful connection using Netcat (Ctrl+C will exit the Netcat session:)

That -w3 says wait three seconds and then give up, which is a nice Netcat-native feature telnet is missing.

Here is what a failed connection looks like in Netcat:

Netcat also supports listening on ports for incoming connections, as well as basic port scanning and some other niceties. These features and the fact that lots of operating systems install Netcat but not telnet by default are why some sysadmins are starting to use Netcat instead of telnet for their troubleshooting needs.

Interacting with services

One final thing: Both of these tools can interact with the service offerings they connect to. If you type syntactically correct protocol messages and hit Enter, you will receive responses from the service. Here is an example:

You may have to hit Enter a few times in the above example. Interacting with service offerings in this fashion gets complicated fast, especially when encryption comes into play, but if you need to test the internals of something—or if you don’t have a better protocol-specific tool like curl around—you can make it work.

Источник