use of very long asymmetric keys in ssh

Hi, $ username. If you are about the same cryptomaniac that I am, then surely do not limit yourself to regeneration of / etc / ssh / moduli, and you want more. For example, use dsa-keys longer than 1024iB for authorization. But the problem is that the ssh-keygen from the OpenSSH package, which is armed with most UNIX'oids, does not want to generate such keys. The reason for this behavior is incomprehensible, man's will be found on a FIPS 186-2 document, which does not really say anything, and there are no references to any sensible explanation of this limitation. Therefore, there are no reasons not to try on all sorts of cryptograbs with long dsa-keys. It remains only to generate such a key. It’s easy to do, but if you don’t want to waste time on all kinds of picks, you can familiarize yourself with the method under the hubracut



This will help openssl. At first we generate parameters for dsa-keys.
')
openssl dsaparam -out parameters.pem 4096

If someone does not know, then 4096 is the desired length of the keys (in bits) that will be generated using these parameters, and the parameters themselves will be recorded (naturally) in the parameters.pem file, which is encoded using base64 binary structure, and provided with a certain cap and an antiskap - all according to the PEM (Privacy-enhanced Electronic Mail) standard. The DSA parameters themselves are three numbers. Details are in en.wikipedia.org/wiki/DSA

After the parameters are generated, you can generate a key (if, of course, you wait for the end of parameter generation :) but in general, if you decide to run it on a cell phone, then book the Perfect Code book — an excellent collection of excellent essays:

openssl dsa -out key.pem parameters.pem

This key is, in fact, two keys - open and closed. If you do not believe, you can see for yourself:

openssl dsa -noout -text < key.pem

Theoretically, you should see your DSA parameters and two small numbers, pub and priv, which, in fact, will be keys.

Now we need to do three things: (1) declare the created key of your (them) identity, (2) extract the public key from the perceived openssh format from it, (3) stick this public key to the authorized_keys machine on the target machine. (2) and (3) will be mixed in one pipeline.

mv key.pem /home/username/.ssh/identity
chown 600 /home/username/.ssh/identity

it is necessary to change access rights, because openssh is a legible thing, because True Theo de Raadt himself guided the project;

ssh-keygen -y -f /home/username/.ssh/identity | ssh username@somehost.ssh tee -a .ssh/authorized_keys

Is done. You can now leave for ssh authentication only on asymmetric keys, and go play chess without fear of a spring aggravation in Latvian-Indo-Chinese-Russian hackers.

PS Of course, PuTTY users can easily generate long DSA-keys with puttygen, but the problem is that puttygen for each new DSA-key generates new parameters, which completely kills all the advantages of DSA over RSA, which is exactly (if not take into account the ability to count on elliptic curves) in the rate of generation of new keys.