Telnet Using Port 22

I have a server with an IPMI interface that can be accessed via Telnet using port 22. I am trying to create a flow that will connect to the IP address using port 22, login using a username and password, then type some commands on the remote system and capture the responses. Easy right??

So far I haven't managed to get beyond the telnet connection using port 22... no matter how much I read on here I just cannot seem to gain a connection that works? Is there anywhere on the forum where I can follow an example of connecting to the IPMI port via telnet using port 22 and entering the username and password?

I figure once I get past that I should be able to figure out the rest... he says with very little idea of how he will do it.

As always, help very much appreciated :slight_smile:

What have you tried so far, could you post your flow so we can see what direction you are talking and any advice we can provide?

Are you using the TCP nodes? Are you using any of the telnet nodes? Are you attempting to script putty?

And port 22 is usually ssh rather than telnet, so will it accept te!net ?

1 Like

good spot - likely is SSH not telnet (but not impossible i suppose - could be a weird implementation)

Hi Steve et al,

I will attempt to try and provide more info... and please bare in mind I am not a super skilled Node Red developer.

Yes, I understand port 22 is SSH territory, but alas that is the only option available to me. The IPMI interface is somewhat dated (it's an older SuperMicro motherboard) and the only option for text based connections appeared to be using Putty with port 22 (SSH) connections.

So... taking above into account, I originally tried the ssh-client node, combined with a function that I was attempting to have it enter the login credentials i.e. username and password. Try as I might I couldn't get the data to go through, and the debug node was spitting out some quite spurious data. Remember, I dont really know what I am doing... so the results could be operator related :slight_smile:

next I moved to a tcp request, and behold underneath the tcp node I received a 'green' connected dot... this was progress I thought. I then attempted to place my trusty function in front of the tcp request node in an attempt to 'login' to the IPMI interface. Here's what I see on Putty...


Hope this info is helping. So, at this stage I am appear to have be 'connected' to the IPMI tcp connection, but am stuck on passing credentials to 'login' to the interface. After I login, I then need to send queries to the IPMI CLI i.e. to obtain information about the status of the server, including temperatures etc.

The commands to the IPMI CLI look something like this...

show /system1/sensors1/sensor002

In my function I added these lines, but I dont think it is correct...

msg.payload = '\n';
msg.payload = 'ADMIN\n';
msg.payload = '<PASSWORD>\n';

Logging in and being able to confirm it has happened would be awesome. Anything else I can provide to show what I have been doing please let me know.

Thanks, Mark

a) maybe try them with delays between them to give the far end time to react.
b) maybe try \r instead - as that is carriage return rather than line feed - some systems expect that.

but meanwhile did you see
9or various other ssh nodes/flows on

Supermicro will only Support SSH - not telent on port 22. Depending on the age it could be SSH1 - but highly unlikely. More likely to be SSH2

What i would suggest would be worth trying would be to generate a key set between the two machines - so you can then login using SSH without password prompting etc.

(I assume your machine that NR is running on is a Linux box)

here is a good topic on it - substitute the 2nd pi for your supermicro management port

If that does not work then give us the exact model and BIOS version so i can confirm capabilities


Might be worth stepping back here a bit and layout my overall objectives. There are a myriad of ways to crack this nut, so sharing my objectives may be the best place to start.

The server running the IPMI is my Centos 8 KVM platform, running a number of VM's. I have a Grafana console that is fed data from a Influx database. I want to add parameters to the grafana dashboard such as CPU temp and other health/status related parameters. And if possible feed the data or real time alerts from Node-Red to my Blynk app.

There are a number of ways the IPMI data can be sourced... via the ipmitool command in the Centos 8 OS running on the IPMI host, via a telnet/ssh connection and the IPMI CLI, or even via a remote IPMI tool from SuperMicro See Here which allows remote connections to IPMI on SuperMicro boards.

Ok, so the method of extracting the IPMI data is unimportant to me i.e. the most simple and reliable method would be the best in my opinion. Unfortunately I have zero experience in doing this via Node-Red, which doesn't help. I could default to a bash script that grabs the data via the linux ipmitool and then pushes it into Influx using the Influx API, but even that has it's challenges.

I hope this background has helped... or perhaps has gone beyond the scope of my original question which is likely to anger some of you... I apologise if that is the case, it is unintended.

Look forward to the collective wisdom on here :slight_smile:

Here's the SuperMicro Main Board I am using: X9DRL-iF

Here's the IPMI manual I have been using as reference: IPMI Manual

Thanks for the tip on the ssh-v2, looks interesting and I will give it a go tonight, time willing. No doubt there is a solution in there somewhere... just need to keep digging :slight_smile:

No worries. Context is king.

Now the node-red part is easy peasy - unfortunately I have no knowledge of IPMI so forgive any ignorance in the following statements and questions...

will node-red be running on the centos server or external?

Node-red can run commands via the exec node and parsing the data is usually pretty easy.

Once you have data in node-red, you have many options for communicating outwards (influx, telegram, mqtt, UDP/TCP sockets etc etc).

Perhaps start with the exec node and see what you get back. There are plenty of really helpful and experienced guys on this forum to help you progress it.

Hi Steve,

The Node-Red, Grafana, InfluxDB, and Mosquito are running on a seperate VM on top of the KVM host. So the VM doesn't have direct access to the IPMI i.e. it cant run the local ipmitool command under the linux OS. So I figure the telnet/ssh or remote IPMI tools are the best options.

Already looked at the exec node but didn't have much luck, will look again.

Thanks, Mark

Your best bet (depending on how heavy you want to be is to run a system monitoring tool on the Centos 8 host - no need to complicate it with IPMI etc - most of that will be presented through to the OS layer.

Have a look initially at Glances, and then at Cockpit (which is now the native Centos 8 tool)

There are a number of tools that will natively push all of this into Grafana for you - telegraf is one

To get some ideas of what you can get (and where it comes from - although a little bit in left field) have a look at this thread (long read) in the HA forum

If you are already comfortable with Docker and VMs - you may want to look at




1 Like

I would collect the desired data on the host and send it via MQTT to the Node-RED.

But is it telnet or is it ssh ? Those are 2 fundamentally different protocols.

If it is telnet you can script it in bash with the expect command (which is interactive, if you need to login, you may need that), there is probably something similar available on windows.

If it is ssh, you can exchange the keys for passwordless login for the correct user and execute commands without login.

Right now I am exploring on two fronts...

  • If I can connect to the IPMI interface and 'login' then I will trial the ssh-v2 node as it sounds interesting.

  • I will also explore the suggestion of using MQTT as I am already running Mosquito, and I will add Telegraf which could provide the answer for me.

I am always open to further ideas, so keep them coming as your generosity is very much appreciated.

Thanks, Mark