When I connect to a machine with ssh user@host it prompts me for a password interactively. I want to run this from a script, so the prompt is a problem — the script stops and waits.
Is there a flag that takes the password on the command line, in the way some other tools accept credentials as arguments?
If there is not, what is the correct way to make this non-interactive?
One detail that catches people setting this up for scripts: if you gave the key a passphrase, you will still be prompted — for the passphrase rather than the password.
That is usually what you want interactively, and you handle it with an agent that holds the key unlocked for your session. For an unattended script running with no human present, you need either a key with no passphrase, restricted to exactly what it needs, or an agent already running with the key loaded.
If you use a passphraseless key, restrict it. On the server, the authorised keys file lets you pin a key to a single command, to specific source addresses, and to disable port forwarding and terminal allocation. A key that can only run one script from one address is a very different risk from one that grants a shell.
That pairing — passphraseless key, tightly restricted — is the standard way to automate this properly.
For completeness, the tool people are usually pointed at is sshpass, which feeds a password to the client through a pseudo-terminal. It exists, it works, and it takes the password either as an argument, from a file, or from an environment variable.
It is worth knowing about because you will meet it in other people's scripts. It is not worth choosing, because every form of it leaves the password somewhere readable, and the file and environment variants are only marginally better than the command line.
The cases where it is genuinely the least bad option are narrow: a device that cannot accept keys at all, or a one-off migration. If you find yourself installing it for ongoing use, that is a sign the underlying setup needs fixing rather than working around.
Worth adding the piece that makes key authentication genuinely pleasant rather than merely correct: the client's config file.
A block in ~/.ssh/config giving a host an alias, a user, a port and a key means your script says ssh myserver and nothing else. No flags, no paths, no repetition, and changing the server means editing one file rather than every script.
Most people discover this years after they start using ssh and immediately wish they had not.
@ssh_serkan · 2d ago
There is deliberately no such flag, and understanding why points straight at the right answer.
A password on a command line ends up in your shell history, in the process list where any user on the machine can read it, and often in logs. Every one of those is a place a credential should never be. The client refuses to accept one for that reason, not as an oversight.
The correct solution is public key authentication, which is easier than the workaround and better in every respect:
ssh-keygen -t ed25519to create a key pair if you do not have one. Accept the defaults.ssh-copy-id user@hostto install the public half on the server. This asks for the password once, and only once.ssh user@hostnow connects with no prompt.That is the whole procedure and it usually needs no server configuration at all. For a script, this is the answer — non-interactive, no secret on any command line, and revocable by deleting one line on the server.
Reply
Report