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

Nick Jones nick at dischord.org
Tue Mar 30 20:22:59 UTC 2021


Can you check network interface MTU settings?  A simple 'ip li' should do
the trick.  Make sure they're all the same;  1500 being the default for
Ethernet, or if you've enabled jumbo frames then perhaps 9000.  The key
thing is that they're all exactly the same.

-- 

-Nick


On Tue, 30 Mar 2021 at 21:08, <tengo at tutanota.de> wrote:

> Thanks for all the replies.
>
> Quiet a lot of discussion and suggestions and things I don't quite
> understand.  I'm willing to try more troubleshooting, but for now here's a
> copy of the output from ssh-copy-id with DEBUG3 -
> https://file.re/2021/03/30/ssh-copy-id-debug3/ . It will be available for
> 24 hours.
>
> @Tai - Thanks for your suggestion. I'm not looking for a work around as I
> think this issue is also stopping me from using Ansible to manage the Pi.
>
> For example, if I manually copy the key to the Pi I can SSH without any
> issues. However, if I run a simple Ansible ad-hoc command using the "ping"
> module it hangs too. This module makes its connection with SSH and I'm
> using the same account (pi). I also encountered issues when I tried the ssh
> extension in VS code too. Not too bothered about VS code extension (in
> preview), but it's also using ssh and failing.
>
> None of this is a problem from my other laptop.
>
> -----------
>
>
>
> 30 Mar 2021, 16:48 by dch.tai at gmail.com:
>
> 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
>
>
> --
> 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/56ee1c19/attachment.html>


More information about the EdLUG mailing list