[EdLUG] SSH - ssh-copy-id problem | RPi | Ubuntu.
Roy
roy at crossford.net
Thu Apr 1 18:02:58 UTC 2021
My WiFi access point is dual band.
By default, the two bands appear as separate networks' not allowed to
communicate with each other, even though they are not really.
Regards,
Roy Bamford.
On 31/03/2021 22:42, Andrew Kember wrote:
> Wow! That's such a bizarre situation! Good job spotting the
> commonality though. Well worth a couple of repeated checks, if only to
> observe the magic: "ssh-copy-id fails in the kitchen, works in the
> living room. Now you see it, now you don't!"
>
> I hope your brain-wax hardens again soon (that sounds more odd than I
> was expecting).
>
> Andrew.
>
> On Wed, 31 Mar 2021 at 21:59, <tengo at tutanota.de
> <mailto:tengo at tutanota.de>> wrote:
>
> Update: The issue is fixed and the cause narrowed down, but still
> confusing.
>
> tl;dr It seems like a network issue, but I don't know why.
>
> Here's how I kind of fixed the issue...
>
> My home network is a mix of 2GHz/5GHz WiFi and hardwired
> machines. The Pi in question is on 5GHz WiFi as was the laptop I
> was having problems with.
>
> The other laptop that was not having problems was hardwired. I
> wanted to sanity check this was working by removing the ssh key
> and trying the ssh-copy-id again. As the devices were in different
> rooms I brought them all together in one room. This meant the
> laptop that was not initially having problem was now using 5GHz
> WiFi (no longer hardwired).
>
> When I tried the ssh-copy-id it failed like the other laptop. I
> also have a VM running on the laptop and this encountered the same
> issue. I thought that since they were both working, but now
> aren't, what has changed? The network connection. I changed the
> WiFi from 5GHz to 2GHz and everything worked fine!
>
> I'm completely baffled as to why the ssh-copy-id fails when the
> laptop(s) and Pi are on 5GHz WiFi, but work when the laptops are
> hardwired or on the 2GHz WiFi. Possibly the router?
>
> I've not tried moving the Pi to 2GHz WiFi. I might leave that for
> another day as my brain currently feels like melting candle wax.
>
> Thank you to everyone who got involved. It was pretty cool
> learning a bit more about bash and using debug.
>
> -----------
>
>
>
> 31 Mar 2021, 10:26 by dch.tai at gmail.com <mailto:dch.tai at gmail.com>:
>
> That's a good point Andrew, well spotted. Not so off-the-wall
> as you'd think.
>
> Though Tengo did say there's no problem from the other
> laptop... which makes it look like a client-side problem...
>
> @Tengo - quid of the contents in .ssh/config ?
>
>
> ===
> Tai Kedzierski
>
> EdLUG Maintainer: https://edlug.gitlab.io/
> <https://edlug.gitlab.io/>
>
> Edinburgh Language Meetup Organiser
> https://www.meetup.com/Edinburgh-Language-Exchange-Meetup-Group/
> <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
> <https://www.fsf.org/about/what-is-free-software>
>
>
> On Tue, 30 Mar 2021 at 21:58, Andrew Kember <andrew at kember.net
> <mailto:andrew at kember.net>> wrote:
>
> Time for a left-field idea. This is PiOS right? Raspberry
> pi OS?
>
> When I log in with the default user (pi) using any method,
> and still have the default password set on that account,
> it triggers a message on the console telling me to change
> the password.
>
> Now, that surely should only come up in an interactive
> shell, it doesn't ask for any input either, but I think it
> is specific to PiOS, so ... maybe it's badly implemented
> somehow.
>
> Question: do you still have the default password set, and
> does this problem still happen if you've changed it?
>
> (Told you it was a bit off-the-wall!)
>
> AK
>
> On Tue, 30 Mar 2021 at 21:48, Gordon Gray
> <gordo.gray at gmail.com <mailto:gordo.gray at gmail.com>> wrote:
>
> Hi all. I’m enjoying this thread. My approach to
> problem solve would be the one Tai described: run the
> commands from the script manually.
>
> One thing I noticed though is this line in the debug
> output
>
> debug1: Sending env LANG = en_GB.UTF-8
>
> I suspect you might need to edit your locale as
> described here:
>
> https://unix.stackexchange.com/questions/347914/how-to-set-lc-all-en-gb-utf-8-in-raspbian
> <https://unix.stackexchange.com/questions/347914/how-to-set-lc-all-en-gb-utf-8-in-raspbian>
>
> Cheers,
> Gordon
>
>
> On Tue, 30 Mar 2021 at 21:39, <tengo at tutanota.de
> <mailto:tengo at tutanota.de>> wrote:
>
> Hi Nick,
>
> Both are 1500.
>
> Regards,
>
> John
>
> -----------
>
>
>
> 30 Mar 2021, 21:22 by nick at dischord.org
> <mailto:nick at dischord.org>:
>
> 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 <mailto: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/
> <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
> <mailto: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/
> <https://edlug.gitlab.io/>
>
> Edinburgh Language Meetup Organiser
> https://www.meetup.com/Edinburgh-Language-Exchange-Meetup-Group/
> <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
> <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
> <mailto: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/ <http://jbr.me.uk/>
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk
> <mailto:EdLUG at mailman.lug.org.uk>
> https://lists.edlug.org.uk/mailman/listinfo/edlug
> <https://lists.edlug.org.uk/mailman/listinfo/edlug>
>
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk
> <mailto:EdLUG at mailman.lug.org.uk>
> https://lists.edlug.org.uk/mailman/listinfo/edlug
> <https://lists.edlug.org.uk/mailman/listinfo/edlug>
>
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk
> <mailto:EdLUG at mailman.lug.org.uk>
> https://lists.edlug.org.uk/mailman/listinfo/edlug
> <https://lists.edlug.org.uk/mailman/listinfo/edlug>
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk <mailto:EdLUG at mailman.lug.org.uk>
> https://lists.edlug.org.uk/mailman/listinfo/edlug
> <https://lists.edlug.org.uk/mailman/listinfo/edlug>
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk <mailto:EdLUG at mailman.lug.org.uk>
> https://lists.edlug.org.uk/mailman/listinfo/edlug
> <https://lists.edlug.org.uk/mailman/listinfo/edlug>
>
>
> --
> EdLUG mailing list
> EdLUG at mailman.lug.org.uk <mailto:EdLUG at mailman.lug.org.uk>
> https://lists.edlug.org.uk/mailman/listinfo/edlug
> <https://lists.edlug.org.uk/mailman/listinfo/edlug>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.edlug.org.uk/pipermail/edlug/attachments/20210401/d4b0397c/attachment-0001.html>
More information about the EdLUG
mailing list