Why does SSH not accept echo and printf?
 

Console applications have strayed far from their roots. There is no reason ssh should be so bloated and hacked up that it refuses to accept input in the standard way with echo or printf.

Result is bad password when pressing enter.

Result is bad password when pressing enter.

The -T option is used or ssh spits more garbage from it's mouth.

There is nothing wrong with echo and printf as they work fine with other applications.

I get that there is probably a built in way to pass commands but ssh does not work in the standard way for console applications.

The typical conditioned Linux user response is to Stockholm Syndrome their way into some kind of workaround for lack of a better term. Because of course our assumption was wrong and it has to be done "this way" and "this way only". A lot like the Cathedral and not the Bazaar. We do not have as much choice as we like to think we do.

We should be able to enter commands the "way we think they should work" and they should just work, within reason. There is no reason I should have to search for hours and get more and more frustrated with doing this the way I WANT to do it. Not using some workaround some dude found on a forum. Not using some program-specific jargon to accomplish what Bash primitives are supposed to do already.

I do not trust SSH. How many people in the world understand what this program is doing anyway? Maybe 100? The chance this will be fixed is less than zero because so few people know the codebase and are allowed to commit to it. One giant backdoor to all FOSS systems. I try to keep this trash off as many systems as possible. When Skynet comes, it hopefully won't be knocking on my door.

Because ssh does not accept passwords from stdin and that is the way it has been for a very long time. I think it is due to security reasons but you can always contact the development team and ask them. The source code is available at:

https://www.openssh.com/

Here are a few ways to automate logins with ssh whether you consider them as workarounds or not.
1. keys
2. certificates
3. sshpass
4. expect script

The comment by "michaelk" is spot on. SSH is not primarily a terminal application, it is a security application. Anything that put security information into the environment or free memory in human readable format is totally insecure, thus not supported. Whatever it is that you are trying to do, there is certainly a better way.

I found a solution that was acceptable to me.

I understand what you are saying but I do not agree with what you are saying. To me, anything that is special for "security reasons" leads down a path to closed technology and lockdowns and ultimately undemocratic behavior. It is kind of like goverment super-secrecy that no one has the power to change because security is needed because security! It also reminds me of a think of the children kind of move. Imagine if those of us who have the intelligence to make moving vehicles added speed controls to them because we think we are smarter than everyone else. Wait a minute that already happens. When a person gets a certain amount of knowledge then they can no longer ever be wrong and everything they say goes. Especially if you happen to be a cryptography expert. We "little people" will just have to continue to watch from the sidelines. The woes of not being able to understand elliptic curves and Diffie-Helman Key Exchange.

Fortunately, the OpenBSD people do not have a monopoly on knowledge. I think I used Putty on Windows before I used SSH from the command line anyway. In those days we used Telnet and there was not a thing wrong with it. The idea that master hackers are waiting around every corner to intercept your comms is ludicrous. I also read that SSH keys are not the most secure thing if you do not use drive encryption. Luckily I have never used SSH keys and long passwords have been more than enough for me.

Anyway I am rambling on. Here is the solution. Install the putty-tools package on Ubuntu/Debian/Devuan. I installed just putty to get the tool for "Haiku OS" as an aside. Thanks to eadmaster on this page:
https://serverfault.com/questions/24...-with-password

You can also omit the confusing looking [cmd] part which just runs a command. Instead this will just login after pressing enter on Devuan and immediately on "Haiku OS". Obviously this is best used on an internal network. You do not want a script with your passwords on an unsecured laptop. But you have the choice and the FREEDOM now and you can choose to use it how you want.

Yes you have the freedom to build your own footgun, aim it at your own foot, and pull the trigger yourself. However if you are going to reinvent the wheel, at least invent a better one. The sshpas utility and the Expect scripting language already have head start. So, instead I would recommend taking a closer look at them if you still insist on password authentication. Expect is TCL-based and quite flexible.

However, either SSH keys or SSH certificates would still be considered best practice while also solving the problem of being able to run remote commands as part of a script.

We understand that you do not understand or agree, but we are willing (and trying) to educate you so you can do better.

Meanwhile, none of the old, obsolete, depreciated, insecure tools have been destroyed. If you look for them you can find traditional telnet and telnetd, ftp and ftpd, and the rc tools. Using them is a REALLY, REALLY BAD idea if any of your packets might go anywhere that is not under your control, but in an isolated and controlled secure environment there may be a use case. No one is FORCING you to use better or more secure (or both) tools, that is entirely up to you.

At the same time, how many people really want to hear you complain because you do not like the better, more secure tools being the default? They are the default because that is what sane people who understand the protocols, hardware, software, and risk levels WANT. No sane person wants to be the easy target, that is one big reason (among many) why we do Linux instead of Windows!

I think you can still find an rsh server and use it with no password and no security. For obvious reasons, it is no longer installed or enabled by default.

Why does SSH not accept echo and printf?
 

Is there a lock on front the door of your house?

Or do you prefer to ensure that your freedom is completely unimpeded?

Can anyone enter your house in the name of democracy?

What you're attempting to do might have worked back when we used "telnet" to connect to remote systems.

If user A ran that "echo password | ssh" command and user B was issuing a "ps" command with the correct options, "password" would be visible to user B. Can you trust all the users on the system?