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

[Geetam]

Hi Justin

1) Have you tried increasing the log level to DEBUG2 or DEBUG3 ?

2) another way to get more detailed feedback if the above does not tell us 
(warning: this idea may be a bit tricky because the script nests quite a 
few commands together on one line) it should be possible to run each of the 
commands in the script one by one manually. Then you might get better 
feedback of which command actually fails (at the moment it is a whole 
'nest' of commands on one line, that fails and it is hard to see which one 
is the cause of the failure). Sorry I cannot give more detailed suggestion 
because I would need to use trial an error and I do not have a similar 
environment to try it out.

Good luck
Geetam


---
I don't know
...
I don't know what it is
...
I don't know what it is that I don't know

Isn't it beautiful

On 29 March 2021 19:50:32 Justin B Rye <justin.byam.rye at gmail.com> wrote:

> I was hoping some Pi or ssh expert might leap in with the solution at
> this point, but if not...
>
> tengo at tutanota.de wrote:
>> pi at 192.168.0.14's password:
>> debug1: Authentication succeeded (password).
>> Authenticated to 192.168.0.14 ([192.168.0.14]:22).
>> debug1: channel 0: new [client-session]
>> debug1: Requesting no-more-sessions at openssh.com
>> debug1: Entering interactive session.
>> debug1: pledge: network
>> debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0
>> debug1: Sending environment.
>> debug1: Sending env LANG = en_GB.UTF-8
>> debug1: Sending command: exec sh -c 'cd ; umask 077 ; mkdir -p .ssh && { [ 
>> -z `tail -1c .ssh/authorized_keys 2>/dev/null` ] || echo >> .ssh/authorized_
>> keys ; } && cat >> .ssh/authorized_keys || exit 1 ; if type restorecon 
>> >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi'
>> ```It just hangs at this point.
>
> So it seems to think it's made a connection, but when it sends a
> command to be run at the other end nothing happens?  Well, I suppose
> the next step is to find out what sshd on the remote server thinks is
> going on.  This may again need increased verbosity - if there's a line
> in that machine's /etc/ssh/sshd_config along the lines of
> #LogLevel INFO
> you could change that to
> LogLevel DEBUG
> (then reload/restart/reboot) and then watch the journal messages.
> --
> 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/20210329/3a00a722/attachment.html>