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

Wed Mar 31 09:27:10 UTC 2021

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/

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 21:58, Andrew Kember <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> 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
>>
>> Cheers,
>> Gordon
>>
>>
>> On Tue, 30 Mar 2021 at 21:39, <tengo at tutanota.de> wrote:
>>
>>> Hi Nick,
>>>
>>> Both are 1500.
>>>
>>> Regards,
>>>
>>> John
>>>
>>> -----------
>>>
>>>
>>>
>>> 30 Mar 2021, 21:22 by 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> 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
>>>
>>>
>>> --
>>> 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
>
> --
> 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/20210331/a950906b/attachment.html>