Verifying Trisquel download : md5 and sha256 OK, but GPG failed because key not found

UPDATE
I tried to do the same with sudo, which got me a much better result ("the
no permission" was the hint to try it).
OTOH, I still have a problem with the second step: host not found (see
below).
Any idea why? Plus how come the verification is good even without
completing the second step? Help me understand whatever I'm blindly
doing ;)

user@user-ThinkPad-X200:~$ sudo gpg --list-packets
trisquel-netinst_7.0_amd64.iso.asc
[sudo] password for user:
:signature packet: algo 17, keyid B4EFB9F38D8AEBF1
version 4, created 1414163368, md5len 0, sigclass 0x00
digest algo 2, begin of digest fd dd
hashed subpkt 2 len 4 (sig created 2014-10-24)
subpkt 16 len 8 (issuer key ID B4EFB9F38D8AEBF1)
data: [159 bits]
data: [160 bits]
user@user-ThinkPad-X200:~$ sudo gpg --keyserver keys.gnupg.net
--recv-keys B4EFB9F38D8AEBF1
gpg: requesting key 8D8AEBF1 from hkp server keys.gnupg.net
?: keys.gnupg.net: Host not found
gpgkeys: HTTP fetch error 7: couldn't connect: Success
gpg: no valid OpenPGP data found.
gpg: Total number processed: 0
user@user-ThinkPad-X200:~$ sudo gpg --verify
trisquel-netinst_7.0_amd64.iso.asc trisquel-netinst_7.0_amd64.iso
gpg: Signature made Fri 24 Oct 2014 17:09:28 CEST using DSA key ID
8D8AEBF1
gpg: Good signature from "Trisquel GNU/Linux (Trisquel GNU/Linux signing
key) <name at domain>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the
owner.
Primary key fingerprint: E6C2 7099 CA21 965B 734A EA31 B4EF B9F3 8D8A
EBF1
user@user-ThinkPad-X200:~$

Seems lies the problem lies in the connection to the server. Is Ruben's public key only available on this server?
It doesn't look like it's down, I can't see why I can't find the host, and thus couldn't connect.

Please, help much welcomed!

EDIT

Nevermind, I figured it out. connect to the ip adress, not to the domain name.

It seems you have permission problems in your home or .gnupg directory. Normally you don't need to use sudo for this. You can fix your permissions like this:

sudo chown -R $USERNAME: ~/.gnupg
chmod 700 ~/.gnupg
chmod 600 ~/.gnupg/*

Or just delete the ~/.gnupg directory, if you don't have important GPG keys. :)

Then just do what you've been doing.

Hi Mampir, thanks for the suggestion :)
I just checked the meaning of all these, learned how to type the tilde on the way.
I've typed each line one after the other with sudo each time.

The last line failed though (no such file or directory).
Yet obviously the directory exists, since the first lines seemed to work, and also because I have it in front of my eyes (with a lock, and closing x symbols on).
Without the /*, it worked, though I don't want to try anything else yet, due to the nature of the command.

You are smart to check what the commands do, before executing them. But, they are pretty safe - they don't do anything irreversible. :)

Actually, originally I made a mistake, as the last command should be 'chmod 600 ~/.gnupg/*', not 'chmod 500 ~/.gnupg/*' (my previous post is corrected now).

Commands beginning with 'sudo' are for doing something with admin/super privileges.

Commands like 'chown -R mampir: DIRECTORY' are for making a DIRECTORY and everything in it belong to the user 'mampir'. The ':' after 'mampir' is for making everything also belong to the primary usergroup of 'mampir', which is what you want 99% of the time. '$USERNAME' can be written in place of 'mampir', so everything will become owned by the user executing the command, no matter what his username is.

'chmod 700 DIRECTORY' makes a directory only accessible by you. '7' stands for the permissions: 4 (read) + 2 (write) + 1 (execute), so you can read, write in and execute a file/directory:

4 + 2 + 1 = 7

The two '0' digits are for setting permission on users belonging to your group and for all other users on your system. They are '0' so everything is disallowed for them.

'chmod 600 DIRECTORY/* makes all files within DIRECTORY accessible only by you:

4 (read) + 2 (write) = 6 (read-write)

While directories need to be 'executable' for to be used, most files don't, so that's why it's '600', not '700'. The '*' means 'everything'.

Ah, I didn't notice the addition of permissions, thanks!
It makes a whole lot of sense.

I suppose that being the owner means that I get full permissions back (which for some reason were removed).
Also, at first I thought that chmod 700 followed by 600 was redundant.
But now it should mean that I remove the execute permission from the files within the directory, but not from the directory itself. (I'm gonna learn about what executing means, it will probably make more sense to me).

Actually I ended up using sudo with each line because it wouldn't work otherwise (maybe because of that initial permission problem).

EDIT

The following helped. The question remaining is why remove the execute permission from the files, and not from the directory. I'll try to find out as well.
The read permission grants the ability to read a file. When set for a directory, this permission grants the ability to read the names of files in the directory, but not to find out any further information about them such as contents, file type, size, ownership, permissions.
The write permission grants the ability to modify a file. When set for a directory, this permission grants the ability to modify entries in the directory. This includes creating files, deleting files, and renaming files.
The execute permission grants the ability to execute a file. This permission must be set for executable programs, including shell scripts, in order to allow the operating system to run them. When set for a directory, this permission grants the ability to access file contents and meta-information if its name is known, but not list files inside the directory, unless read is set also.
The effect of setting the permissions on a directory, rather than a file, is "one of the most frequently misunderstood file permission issues".
When a permission is not set, the corresponding rights are denied. Unlike ACL-based systems, permissions on Unix-like systems are not inherited. Files created within a directory do not necessarily have the same permissions as that directory.