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

[tengo at tutanota.de]

I realised the output in the other file only contained data to the point the the utility/script hangs. Below is a link to the full output which includes the part after I cancel it. Strangely, it states the key was added. I can confirm it's not in the ".ssh/authorized_keys" file on the Pi,

https://file.re/2021/03/30/ssh-copy-id-debug3-1/

-----------



30 Mar 2021, 21:07 by :

> 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
>>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.edlug.org.uk/pipermail/edlug/attachments/20210330/d638661b/attachment-0001.html>