[Bug 2765] New: ssh-copy-id appears to hang indefinitely when the target user has no password
bugzilla-daemon at bugzilla.mindrot.org
bugzilla-daemon at bugzilla.mindrot.org
Fri Aug 25 20:57:30 AEST 2017
https://bugzilla.mindrot.org/show_bug.cgi?id=2765
Bug ID: 2765
Summary: ssh-copy-id appears to hang indefinitely when the
target user has no password
Product: Portable OpenSSH
Version: 6.6p1
Hardware: All
OS: Linux
Status: NEW
Severity: trivial
Priority: P5
Component: ssh-copy-id
Assignee: unassigned-bugs at mindrot.org
Reporter: ymbirtt at gmail.com
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 at 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 at 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.
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list