I finally figured out, by accident, why I could not access science and x11 overlay. I tried to delete the existing copy and re-create but that failed in the same way as did the attempt to update. After pressing ctrl+c, I was asked by ssh to accept the new, untested key of the server. I guess "ssh -o StrictHostKeyChecking=no" or similar has to be executed somewhere under the hood. ;-) # layman -d science * Deleting directory "/usr/local/portage/layman/science" * Successfully deleted overlay "science". # layman -a science * Running command "/usr/bin/git clone "git://git.overlays.gentoo.org/proj/sci.git" "/usr/local/portage/layman/science""... Initialized empty Git repository in /usr/local/portage/layman/science/.git/ fatal: read error: Connection reset by peer * Failed to add overlay "science". * Error was: Adding overlay "science" failed! # # layman -a x11 science * Running command "/usr/bin/git clone "git://git.overlays.gentoo.org/proj/x11" "/usr/local/portage/layman/x11""... Initialized empty Git repository in /usr/local/portage/layman/x11/.git/ fatal: read error: Connection reset by peer * Running command "/usr/bin/git clone "http://git.overlays.gentoo.org/gitroot/proj/x11.git/" "/usr/local/portage/layman/x11""... Initialized empty Git repository in /usr/local/portage/layman/x11/.git/ ^C* Running command "/usr/bin/git clone "git+ssh://git@git.overlays.gentoo.org/proj/x11.git" "/usr/local/portage/layman/x11""... Initialized empty Git repository in /usr/local/portage/layman/x11/.git/ The authenticity of host 'git.overlays.gentoo.org (66.219.59.40)' can't be established. RSA key fingerprint is f0:11:07:30:1a:04:06:7c:16:a6:a8:1c:7b:7e:45:9e. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'git.overlays.gentoo.org,66.219.59.40' (RSA) to the list of known hosts. Permission denied (publickey). fatal: The remote end hung up unexpectedly * Failed to add overlay "x11". * Error was: Adding overlay "x11" failed! # # layman -a x11 science * Running command "/usr/bin/git clone "git://git.overlays.gentoo.org/proj/x11" "/usr/local/portage/layman/x11""... Initialized empty Git repository in /usr/local/portage/layman/x11/.git/ remote: Counting objects: 8317, done. remote: Compressing objects: 100% (5694/5694), done. remote: Total 8317 (delta 3983), reused 5694 (delta 2561) Receiving objects: 100% (8317/8317), 1.42 MiB | 29 KiB/s, done. Resolving deltas: 100% (3983/3983), done. * Successfully added overlay "x11". #
What do you propose to fix this? It doesn't look fixable to me.
I did not look into the code of the tool but I suppose this ("ssh -o StrictHostKeyChecking=no") would help as long as the admin of the client computer did not forbid this in /etc/ssh/ssh_config file?
I really don't see that such configuration would be something that should be in Layman. Would you mind if I closed this as "wontfix"?
Alternatively, and that is probably the only correct way, layman should leave STDERR assigned to the terminal, as well as STDIN, so that the interactive ssh session could reach the user if necessary.
(In reply to comment #4) > Alternatively, and that is probably the only correct way, layman should leave > STDERR assigned to the terminal, as well as STDIN, so that the interactive ssh > session could reach the user if necessary. I now checked: In layman 1.3.1 stdin is forwarded to the child process. stderr is forwarded to the outside, unless in quiet mode. From the next release on stdin will be closed in quiet mode.
(In reply to comment #2) > I did not look into the code of the tool but I suppose this ("ssh -o > StrictHostKeyChecking=no") would help as long as the admin of the client > computer did not forbid this in /etc/ssh/ssh_config file? To my current understanding a proper fix would be to fix the hosts key in ~/.ssh/known_hosts. I think I understand the issue now and I'm closing this as invalid: this issue is meant to be handled outside of layman. I do not mean to kill the discussion: if there is need to further discuss this, be encouraged to re-open this bug. Thanks.
(In reply to comment #6) > (In reply to comment #2) > > I did not look into the code of the tool but I suppose this ("ssh -o > > StrictHostKeyChecking=no") would help as long as the admin of the client > > computer did not forbid this in /etc/ssh/ssh_config file? > > To my current understanding a proper fix would be to fix the hosts key in > ~/.ssh/known_hosts. Yes, as long I get the error message from underlying ssh. If that will be fixed in the upcoming 1.3.1 ... The point is that I only figured that out when I interrupted layman by ctrl+c. Second, I still do think this will not work because you seem to run ssh in a mode that it asks the user to add a new key (although the STDERR of ssh does not reach users eyes nor its STDIN), and therefore I believe if the current key does not match the one in known_hosts it will not replace it and the user will not know what is going on. Try to alter the keys in known_hosts and test yourself with the future version. Can you/layman replace a key for same hostname/IP? Can you/layman add a new key?
I did some more research on this, still some questions on your feedback remain: > Second, I still do think this will not work because you seem to run ssh in a > mode that it asks the user to add a new key (although the STDERR of ssh does > not reach users eyes nor its STDIN), and therefore I believe if the current key > does not match the one in known_hosts it will not replace it and the user will > not know what is going on. Stdin and stderr are not connected to the run SSH? Are you sure? Can you test this with 1.4.0? Are you aware that if layman is run as root, git an the SSH client run by that (not layman) will be run as root and therefor look for $HOME/.ssh/config of root (usually /root/.ssh/config)? > Try to alter the keys in known_hosts and test yourself with the future version. > Can you/layman replace a key for same hostname/IP? Can you/layman add a new > key? Tried that. I get RSA host key for $HOST has changed and you have requested strict checking. Host key verification failed. I tested with Host * StrictHostKeyChecking=no in /root/.ssh/config and it works, but is dangerous and advised against. Another way you could do is run layman with GIT_SSH=/usr/bin/layman-git-ssh and put something like this into an executable file of that name: #!/bin/sh exec ssh --your-options-- "$@" Disabling strict host checking remains a bad idea to me, still. Whether GIT_SSH support needs tighter integration with layman is discussable. Looking forward to your reply.
Solution/workaround explained in comment #8. Closing. Please re-open as needed.
