Re: Permission denied

2020-11-13 Thread Isaac Keslassy

A quick email to future users that get this problem:

The solution is actually straightforward. I simply forgot that it was 
mentioned in the manual 
(https://savannah.gnu.org/maintenance/SshAccess/). When we get the error 
message "Sorry, you are not allowed to execute that command" after 
typing ssh, it does not mean that we need sudo rights (and it is quite 
confusing because with sudo we do encounter a different behavior). It 
actually means that the ssh worked well and we can move on.


Many thanks again to Bob for his very kind answer!

- Isaac


On 12-Nov-20 8:46 AM, Isaac Keslassy wrote:

Many thanks for your extremely kind answer, I really appreciate it!

I pasted the right key format in the webpage and waited for several 
hours, but am still unable to connect. Now ssh has started asking for 
sudo rights, I'm not sure whether it's a good or bad thing...


Sorry again for the very basic questions, and many thanks again! Full 
details below.


-- Isaac


isaac@isaac-VirtualBox:~/gnubg/cvs$ ssh p...@cvs.savannah.gnu.org
Linux vcs1 4.9.0-14-amd64 #1 SMP Debian 4.9.240-2 (2020-10-30) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Nov 12 00:25:01 2020 from 109.67.23.244
You tried to execute:
Sorry, you are not allowed to execute that command.
Connection to cvs.savannah.gnu.org closed.

isaac@isaac-VirtualBox:~/gnubg/cvs$ sudo ssh p...@cvs.savannah.gnu.org
[sudo] password for isaac:
p...@cvs.savannah.gnu.org's password:
Permission denied, please try again.

isaac@isaac-VirtualBox:~/gnubg/cvs$ sudo ssh -v p...@cvs.savannah.gnu.org
OpenSSH_8.2p1 Ubuntu-4ubuntu0.1, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include 
/etc/ssh/ssh_config.d/*.conf matched no files

debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to cvs.savannah.gnu.org [209.51.188.81] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: Remote protocol version 2.0, remote software version 
OpenSSH_7.4p1 Debian-10+deb9u7
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 pat 
OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* 
compat 0x0402

debug1: Authenticating to cvs.savannah.gnu.org:22 as 'pif'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none
debug1: kex: client->server cipher: chacha20-poly1...@openssh.com MAC: 
 compression: none

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 
SHA256:qRLLJ4w/GAeiDyYnbx4yWJbZXwGiYYxgNty7lAfUyuM
debug1: Host 'cvs.savannah.gnu.org' is known and matches the ECDSA host 
key.

debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_ed25519_sk
debug1: Will attempt key: /root/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: 
server-sig-algs= 


debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: 

Re: Submission of libre-sapienza to NonGNU Savannah

2020-11-13 Thread Andrea Monaco


 >  THanks for pointing this out to me, and please be patient now
 >  since changing things like this can take time.

Thank you. Please take your time, I am in no hurry.



Dependence on nonfree software

2020-11-13 Thread Richard Stallman
[[[ To any NSA and FBI agents reading my email: please consider]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The rules for hosting packages on Savannah say that the package
must not depend on any nonfree software.  It turns out that this
criterion is unclear.

That is meant reject packages that need the user to install
some nonfree software on per own computer and run it there.
Running nonfree software means surrendering freedom, and we
don't want Savannah packages to encourage users to do that.

However, there is a different case which has arisen: where the package
communicates with a service which is (or might be) implemented by
nonfree software running on someone else's server.

Morally speaking, that is a totally different issue.  The service
may be good, or it may be bad (a dis-service), but either way
using the service does not mean you run nonfree software yourself.

So I think the Savannah hosting rules need to be modified
to say that the criterion is about nonfree software to be run
on the user's own computers, and that it does not apply to
communication with services run by other people or entities.

Would someone like to work on a draft of this change?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)