I'm trying to create a signed zone file, but previous examples are not working for me. See below
[root#dnsserv1 named]# dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -n ZONE example.edu
Generating key pair.........................+++++ ..............................................+++++
example.edu.+005+56778
# Create KSK
[root#dnsserv1 named]# dnssec-keygen -r /dev/random -a RSASHA1 -b 1024 -n ZONE -f KSK example.edu
Generating key pair........................................................................+++++ ..........+++++
example.edu.+005+27182
[root#dnsserv1 named]# dnssec-signzone -o example.edu -k 'example.edu.+005+56778' example.edu.zone 'example.edu.+005+27182.key'
dnssec-signzone: warning: example.edu.zone:1: no TTL specified; using SOA MINTTL instead
dnssec-signzone: fatal: failed to find keys at the zone apex: not found
This "failed to find keys at the zone apex: not found" error doesn't seem like it's common. If I search for it on Google, almost nothing comes up. Did I forget to do something? I've tried many different variants on what's shown above.
Related
I've got a private Github repo I want to access from two different Linux machines using the same set of ssh keys
For the first machine, I followed Github's instructions for generating SSH keys, and added the resulting public key to Github. This client works fine.
i uplaoded both my private and public key in GitHub gists to easily wget it on second client
In the second machine , I downloaded the the private and public key to the necessary directory and gave relevant permissions.
wget -O /root/.ssh/id_rsa.pub URL(RAW)
wget -O /root/.ssh/id_rsa URL(RAW)
chmod 700 /root/.ssh
chmod 600 /root/.ssh/id_rsa
chmod 600 /root/.ssh/id_rsa.pub
I thought this might be all I had to do, but when I try to connect i get the following error
root#InstanceIDInHexa:~# ssh -T git#github.com
The authenticity of host 'github.com (xxx.xxx.xxx.xxx)' can't be established.
RSA key fingerprint is SHA256:RandomStringOfAlphaNumericCharacters.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,xxx.xxx.xxx.xxx' (RSA) to the list of known hosts.
Load key "/root/.ssh/id_rsa": invalid format
git#github.com: Permission denied (publickey).
root#InstanceIDInHexa:~#
I also checked the content and permissions of all the files and it looks good
cat /root/.ssh/id_rsa
cat /root/.ssh/id_rsa.pub
stat -c "%a" /root/.ssh
stat -c "%a" /root/.ssh/id_rsa
stat -c "%a" /root/.ssh/id_rsa.pub
is there something i am missing here ?
First of all, the best practice is to have one key per user per machine. That's the most secure approach, because it means you can remove access from one machine independent from the other, such as if one machine is lost or stolen.
However, having said that, if you really want to do this and want to ignore best practices, you can copy the id_rsa and id_rsa.pub files to a different machine, and that should work. However, in this case, you generated the key on a newer machine which uses a different private key format or a more modern encryption algorithm for encrypting it then the older machine. The default encryption for older RSA keys, the PKCS #1 format, tends to leave a lot to be desired and isn't very secure.
The easiest, simplest way to solve this problem is to generate a new Ed25519 key pair because those always use the OpenSSH format, and you can do that with ssh-keygen -t ed25519. If you want to then copy it, the files are ~/.ssh/id_ed25519 and ~/.ssh/id_ed25519.pub. This is also the most preferred key format these days, but if you're using something ancient like CentOS 6, then it may not be supported.
If you don't want to do that, then you can convert the existing private key using ssh-keygen -i and ssh-keygen -e to convert your private key to the appropriate format. This should be done on the newer machine, the one that generated the key. The manual page documents the options and formats supported. You can use file on that machine to find out the format that the private key is in.
I have a file that contains ~1000 hosts, one host per line. For each host, I want to check if an entry for the host already exists in the known_hosts file. If one does not, I want to add the host to the known_hosts file. Otherwise, I want to update the existing entry. I would like to use the -H option to hash all entries in known_hosts. I have already run the command ssh-keygen -H ~/.ssh/known_hosts to hash the existing entries.
Here is a simple loop that I put together:
while read LINE; do
# Remove entry if it exists
ssh-keygen -R $LINE
# Append new hashed key to file
ssh-keyscan -H $LINE >> ~/.ssh/known_hosts
done < $HOST_FILE
Is this method secure? If not, what is the recommended way of doing this? The reason I am doing this is to disable typing "yes" 1000 times to allow every new host to be added to known_hosts for scripting purposes.
What's interactive here? You're piping data into your while loop and neither of the commands in the loop involve user interactivity. I see this as secure.
Note: ssh-keyscan drops comments to standard error and you might want to filter them out. You probably also don't need the errors from ssh-keygen when the requested host isn't present:
while read LINE; do
# Remove entry if it exists
ssh-keygen -R "$LINE" 2>/dev/null
# Append new hashed key to file
ssh-keyscan -H "$LINE" >> ~/.ssh/known_hosts 2>/dev/null
done < "$HOST_FILE"
You may also be interested in ssh-hosthashes, a script I wrote a while back that looks for duplicate entries in known_hosts files. This finds duplicates by the public keys, so it will cluster entries regardless of whether they are listed by IP, name, or hash.
I have 2 systems that I use almost daily. One is desktop located within office premises and another one is laptop. Both are running Ubuntu LTS linux.
I know that SSH keys generated on one system can be copied to another system and it won't break anything like pushing/committing. But I don't want to do that. I need to track from which system I had push/committed the code.
To achieve that I have added 2 diff. emails to my GitHub account.
john+desktop#gmail.com
john+laptop#gmail.com
Now I need to generate diff. SSH keys on desktop and laptop, but I don't know how to do that.
A friend of mine suggested me to read this article. Step 2 shows following code
ssh-keygen -t rsa -b 4096 -C "your_email#example.com"
# Creates a new ssh key, using the provided email as a label
Generating public/private rsa key pair.
Above command has provision to pass email address, but it mentions email address as a label. I didn't understand label part of the command.
Should below commands solve my query?
ssh-keygen -t rsa -b 4096 -C "john+desktop#gmail.com"
ssh-keygen -t rsa -b 4096 -C "john+laptop#gmail.com"
According to the ssh-keygen manual the -C parameter is used to provide a comment.
-C comment
Provides a new comment.
This comment is useful to remember what the key is for. On github, setting the comment to the email helps you remember for which email account you are using that specific key.
Your commands will definitely solve your problem but also theese will do the trick
ssh-keygen -t rsa -b 4096 -C "github key number desktop"
ssh-keygen -t rsa -b 4096 -C "github key number laptop"
You can change the comment later by editing the pub file with any text editor.
This is my code:
ssh-keygen -t rsa -C "$APP"
This works perfectly. However it then asks me to specify location and password. I was hoping I can automate this all in one go, however this command fails:
ssh-keygen -t rsa -C "$APP" -P "$SSHKEYPASS" -T ~/.ssh/id_rsa.pub
This command seems to fail though, when I specify the password I want for the key and location in the same line. I don't really understand the man page:
http://linux.die.net/man/1/ssh-keygen
Can anyone tell me where I have gone wrong?
-P is for the old passphrase, to create a key I assume you want -N for the new passphrase.
-T is for DH group test output it appears (not that I know what that is exactly).
You want -f to specify the key filename. And you specify the private key file not the public key file.
So try:
ssh-keygen -t rsa -C "$APP" -N "$SSHKEYPASS" -f ~/.ssh/id_rsa
I know this is more like a serverfault question than a stackoverflow question, but since serverfault isn't up yet, here I go:
I'm supposed to move an application from one redhat server to another, and without very good knowledge of the internal workings of the application, how would I move the OpenLDAP database from the one machine to the other, with schemas and all.
What files would I need to copy over? I believe the setup is pretty standard.
The problem with SourceRebels' answer is that slapcat(8) does not guarantee that the data is ordered for ldapadd(1)/ldapmodify(1).
From man slapcat (from OpenLDAP 2.3) :
The LDIF generated by this tool is suitable for use with slapadd(8).
As the entries are in database order, not superior first order, they
cannot be loaded with ldapadd(1) without first being reordered.
(FYI: In OpenLDAP 2.4 that section was rephrased and expanded.)
Plus using a tool that uses the backend files to dump the database and then using a tool that loads the ldif through the ldap protocol is not very consistent.
I'd suggest to use a combination of slapcat(8)/slapadd(8) OR ldapsearch(1)/ldapmodify(1). My preference would go to the latter as it does not need shell access to the ldap server or moving files around.
For example, dump database from a master server under dc=master,dc=com and load it in a backup server
$ ldapsearch -Wx -D "cn=admin_master,dc=master,dc=com" -b "dc=master,dc=com" -H ldap://my.master.host -LLL > ldap_dump-20100525-1.ldif
$ ldapadd -Wx -D "cn=admin_backup,dc=backup,dc=com" -H ldap://my.backup.host -f ldap_dump-20100525-1.ldif
The -W flag above prompts for ldap admin_master password however since we are redirecting output to a file you wont see the prompt - just an empty line. Go ahead and type your ldap admin_master password and enter and it will work. First line of your output file will need to be removed (Enter LDAP Password:) before running ldapadd.
Last hint, ldapadd(1) is a hard link to ldapmodify(1) with the -a (add) flag turned on.
ldapsearch and ldapadd are not necessarily the best tools to clone your LDAP DB. slapcat and slapadd are much better options.
Export your DB with slapcat:
slapcat > ldif
Import the DB with slapadd (make sure the LDAP server is stopped):
slapadd -l ldif
Some appointments:
Save your personalized schemas and objectclasses definitions on your new server. You can look for your included files at slapd.conf to obtain it, for example (this is a part of my slapd.conf):
include /etc/ldap/schema/core.schema
Include your personalized schemas and objectclasses in your new openLDAP installation.
Use slapcat command to export your full LDAP tree to a single/various ldif files.
Use ldapadd to import the ldif files on to your new LDAP installation.
I prefer copy the database through the protocol:
first of all be sure you have the same schemas on both servers.
dump the database with ldapsearch:
ldapsearch -LLL -Wx -D "cn=admin,dc=domain" -b "dc=domain" > domain.ldif
and import it in the new server:
ldapmodify -Wx -D "cn=admin,dc=domain" -a -f domain.ldif
in one line:
ldapsearch -LLL -Wx -D "cn=admin,dc=domain" -b "dc=domain" | ldapmodify -w pass -x -D "cn=admin,dc=domain" -a
By using the bin/ldap* commands you are talking directly with the server while using bin/slap* commands you are dealing with the backend files
(Not enough reputation to write a comment...)
Ldapsearch opens a connection to the LDAP server.
Slapcat instead accesses the database directly, and this means that ACLs, time and size limits, and other byproducts of the LDAP connection are not evaluated, and hence will not alter the data. (Matt Butcher, "Mastering OpenLDAP")
Thanks, Vish. Worked like a charm! I edited the command:
ldapsearch -z max -LLL -Wx -D "cn=Manager,dc=domain,dc=fr" -b "dc=domain,dc=fr" >/tmp/save.ldif
ldapmodify -c -Wx -D "cn=Manager,dc=domain,dc=fr" -a -f /tmp/save.ldif
Just added the -z max to avoid the size limitation and the -c to go on even if the target domain already exists (my case).