Bug 2765 - ssh-copy-id appears to hang indefinitely when the target user has no password
Summary: ssh-copy-id appears to hang indefinitely when the target user has no password
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: ssh-copy-id (show other bugs)
Version: 6.6p1
Hardware: All Linux
: P5 trivial
Assignee: Philip Hands
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-25 20:57 AEST by ymbirtt
Modified: 2023-01-31 17:14 AEDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ymbirtt 2017-08-25 20:57:30 AEST
This is, obviously, a pretty bizarre use-case. Copying an SSH ID to a passwordless user doesn't actually add any security, but it's still a werid issue that ssh-copy-id probably shouldn't exhibit. This can be reproduced on a single node as follows:

$ sudo adduser dimwit
$ sudo passwd -d dimwit # Never do this
$ ssh-copy-id dimwit@localhost
# The shell now appears to hang...

The issue seems to be with a line containing a call to "ssh -v -o PreferredAuthentications=','", which attempts to assign a value to the $REMOTE_VERSION variable.

A little investigative work revealed that this call successfully negotiates an interactive shell with all its output piped into sed, so not echoed back to the user. CTRL-C and CTRL-Z get passed down to this contained shell meaning that these will not exit the process - the terminal really does appear to lock up. However...

$ echo "touch i-woz-ere" | ssh-copy-id dimwit@localhost
# This rapidly completes
$ su dimwit
$ ls ~
i-woz-ere

It is still possible to interact with this shell.

This does not present any real security vulnerabilty, in fact it is caused by a complete lack of any security on the user's part, however spawning an interactive shell does not appear to be intended behaviour.

Replacing the call with "ssh -v -o PreferredAuthentications=',' < /dev/null" resolves this issue.
Comment 1 Philip Hands 2020-09-17 06:07:33 AEST
Sorry for not doing anything about this bug till now.

I was just trying to reproduce it, before fixing it, and am failing to do so.

I've tried this by hand, and I note that I'm being prompted for a password, and simply hitting return does not allow me to log in.

I've also added this to the automated tests:

  https://gitlab.com/phil_hands/ssh-copy-id/-/tree/bug/2765

but (assuming the logs are still there by the time you read this) you'll see here:

  https://gitlab.com/phil_hands/ssh-copy-id/-/jobs/741757388

that it prompts for the user's password repeatedly, and the test doesn't manage to log in, so it also fails to provoke the behaviour.

I'm not aware of any problem with adding a </dev/null but it would be nice to be able to demonstrate that it's needed.

Cheers, Phil.