[EdLUG] SSH - ssh-copy-id problem | RPi | Ubuntu.

Tai Kedzierski dch.tai at gmail.com
Tue Mar 30 15:49:19 UTC 2021


Back on track :-)

You could try running as Geetam suggested

    ssh-copy-id -o LogLevel=DEBUG3 pi@$IP

for even more verbose output (equivalent to running ssh -vvv ...)


If you "just want it to work", and regular SSH seems to work, you could
instead run this:

    akeysfile=".ssh/authorized_keys"
    ssh pi@"$IP" "cd ; umask 077 ; mkdir -p .ssh && touch $akeysfile && cat
>> $akeysfile" < "$HOME/.ssh/id_rsa.pub"

This is the simplified version of what ssh-copy-id tries to do, except the
latter does extra checking of various things. This one just bluntly and
forcibly append your existing public id content to the remote auth keys
file. Manually adding a key is what I do to grant access to other people
onto boxes, this technique is fine.


>From reading the ssh-copy-id script, I can see it does some complex
jiggery-pokery with trying to read the public key file and determine if
it's the latest, if it's already over on the other side, etc. That it
prompts means there's a connection. That it hangs on that command, makes it
sound like the printf isn't doing what is expected and the `cat` being run
on the remote side isn't receiving data, OR that the server is trying to
prompt you somehow but you are not seeing that prompt, which is unlikely
but I've seen weirder, I'm sure.

Which leads me to still suspect as Andrew Kember mentioned that X11 might
be getting in the way, or some other SSH option causing the client to wait
for the server to supply something and the two are in disagreement. Once
sanitized, could you send the contents of ~/.ssh/config (or, look there to
see if there is any mention of xauth or X11 ?) I most often don't have
anything in that config, so if it's heavily populated, you might need to
weed around it.... or, try renaming it temporarily so that it does not take
effect.


Note that if you are somehow trying to include ssh-copy-id inside as a
recipient in a pipe, it will play silly diggers with you, so don't pipe
anything into the script.


Good luck, cod speed.



===
Tai Kedzierski

EdLUG Maintainer: https://edlug.gitlab.io/

Edinburgh Language Meetup Organiser
https://www.meetup.com/Edinburgh-Language-Exchange-Meetup-Group/

*Open Source Free Software is a matter of liberty, not price.*
https://www.fsf.org/about/what-is-free-software



On Tue, 30 Mar 2021 at 16:05, Justin B Rye <justin.byam.rye at gmail.com>
wrote:

> Robert McWilliam wrote:
> > On Tue, 30 Mar 2021, at 13:09, Justin B Rye wrote:
> >>> pstree -sup $(ps aux | grep sshd |  awk '{print $2}' | sort -n | head
> -n 1)
> >>>
> >>
> >> As a general rule of thumb, any complicated pipeline like that is
> >> really a job for pgrep (which you probably get in the same package as
> >> ps).  The above simplifies down to
> >>
> >>  pstree -sup $(pgrep sshd)
> >
> > You've thrown away a bit too much of the pipeline there: pgrep will
> > give multiple results if there are SSH sessions and only want one for
> > pstree so need the head part (and possibly the sort - I think ps and
> > pgrep will give processes in order of PID without having to sort but
> > chucking sort in the pipeline was quicker than checking).
>
> When you want the oldest, that's "pgrep -o sshd"; taking the lowest
> number will mess up if the PIDs wrap around.  Mind you, I was
> surprised by how hard it has become to do this - I hadn't previously
> noticed that /proc/sys/kernel/pid_max has gone up from 32,768 on my
> old stable desktop to 4,194,304 on my testbed machine!
>
> [...]
> > Yes, just explaining where to manually copy the PID from is probably
> > easier, but where's the fun in that :)
>
> I hope you'll forgive me my addiction to shell golf then!
> --
> Justin B Rye
> http://jbr.me.uk/
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk
> https://lists.edlug.org.uk/mailman/listinfo/edlug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.edlug.org.uk/pipermail/edlug/attachments/20210330/1bcf5fd9/attachment-0001.html>


More information about the EdLUG mailing list