I recommend the Secure Secure Shell article, which suggests:
ssh-keygen -t ed25519 -a 100
Ed25519 is an EdDSA scheme with very small (fixed size) keys, introduced in OpenSSH 6.5 (2014-01-30). These have complexity akin to RSA at 4096 bits thanks to elliptic curve cryptography (ECC). The -a 100 option specifies 100 rounds of key derivations, making your key'...
This is a good question. The dedicated page from OpenSSH only says:
OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.
which is no more detailed than the "inherit weakness" from the announce. I did not find any published explanation about these weaknesses except some ...
First off, here's the full man page entry for ssh-keygen -o from my machine (ssh-keygen doesn't seem to have a version flag, but the man page is from February 17, 2016)
-o Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format. The new format has increased resistance to brute-force password ...
Like Steve Sether said, this is not a man-in-the-middle attack.
How dangerous is it?
In some cases, buffer overflow attacks are possible.
Your private SSH keys can be leaked to an attacker.
According to the page:
SSH roaming enables a client, in case an SSH connection breaks
unexpectedly, to resume it at a later time, provided the server also
Most users would simply type ssh-keygen and accept what they're given by default.
Yes. To do a security for people, it needs to be simple. Therefore the default option should be safe, compatible and fast. You can provide alternatives, but default should be "good enough" for these who don't care. Therefore RSA (2048) in the old PEM format is the default at ...
Why remove primes shorter than 2000 bits? According to RFC4419, the key exchange starts with the client sending its preferences to the server in the form of 3 numbers:
the minimum acceptable modulus length,
the maximum acceptable length
and the preferred length.
Then the server chooses a random prime that best satisfies this ...
On most systems, OpenSSH supports AES, ChaCha20, Blowfish, CAST128, IDEA, RC4, and 3DES. I am assuming you are talking about the symmetric ciphers used. If you are also wondering about the HMAC and key exchange, I can edit my answer to explain which of those are strong or weak as well.
AES and ChaCha20 are the best ciphers currently supported. AES ...
Throw out < 2048 bit builtin moduli
On the server: Have a look at your sshd_config and throw out the diffie-hellman-group1-sha1 if it appears in the KexAlgorithms section.
And restart SSHD.
Check with Nmap
how can I test if that is good enough?
Get Nmap and run the `ssh2-enum-algos' script against the SSH server.
The diffie-hellman-group1-sha1 must not ...
https://bugzilla.mindrot.org/show_bug.cgi?id=1647 has the reasoning behind the restricting DSA keys to 1024 bits, but basically:
RFC4253 section 6.6 requires the SHA1 hash (160 bits) for ssh-dss (ie DSA) authentication.
FIPS 186-3 section 4.2 requires DSA keys >1024 bits to use a hash stronger than 160 bits.
the only way to comply with both is to allow only ...
could cause remote code execution
No remote code execution. No man-in the middle as it was cleared up by Mark. Everything is explained in the Qualys analysis as already linked.
But in short:
The vulnerable thing is implementation of the Roaming feature in client. Client stores buffer of not send bytes if the connection is suspended. The vulnerable, badly ...
I run https://serveo.net/. It provides a stable subdomain as you require, and as an added benefit, it uses SSH port forwarding, so you probably don't even need to install anything—just use your SSH client.
Use it like this (where localhost:9000 is the address you want to forward to):
ssh -R 80:localhost:9000 serveo.net
Or, to make sure you get a ...
Just open it, if it's encrypted it will begin with
-----BEGIN RSA PRIVATE KEY-----
if it is not it will begin directly by the (base64 encoded) key :
-----BEGIN RSA PRIVATE KEY-----
Compression before encryption is a problem if the attacker can control parts of the transferred data and then use the detectable compression ratio (i.e. amount of transferred data vs. original data) to make conclusions about some of the traffic. This was in TLS used within BREACH and CRIME attacks to infer cookies and CSRF tokens. Making such attacks work ...
I don't think, there was any vulnerability in this, at least not in openssh. The code resulting in this error was added in this commit and it is referencing recommendation from ietf-drafts. Probably RFC4252, which states today:
The 'user name' and 'service name' are repeated in every new
authentication attempt, and MAY change. The server implementation
Here's a one liner for Ed25519 based on recommended values: (without passphrase)
ssh-keygen -t ed25519 -a 100 -f ~/.ssh/id_ed25519 -q -N ''
Another one for RSA:
ssh-keygen -t rsa -b 4096 -o -a 100 -f ~/.ssh/id_rsa -q -N ''
-N: New passphrase
-q: Silence ssh-keygen
Edit & disclaimer:
To answer some comments, this answer focus on simplicity, and ...
Yes, you have to trust the remote server if you allow agent forwarding for this server (especially if you use the same key for more services). Doing so rogue root or evil admin with root access can impersonate you for authentication to other servers during the time you are connected to that server.
The state is still better than accessing the key ...
Is there some logical reason for this, or is it a bug?
It's not a bug, it is a feature. The line with the comment is written to stderr unlike the host keys, therefore it is no problem if you do
ssh-keyscan -H -t rsa host > /your/known_hosts
The list of hosts will go to your terminal and not into the file.
ssh-keyscan -H -t rsa host 2> /...
No. You can't enforce on the server side that the key has passphrase. Key is always on the client side and the server sees only the signature of challenge and public key. Certificates (aka signed keys) will not help either, because the public keys are signed.
I propose you to have a look at some kind of two factor authentication or smart cards if you want ...
You don't need to do anything to your keys. From the same page that you quoted:
The better alternatives include:
The RFC8332 RSA SHA-2 signature algorithms rsa-sha2-256/512. These
algorithms have the advantage of using the same key type as
"ssh-rsa" but use the safe SHA-2 hash algorithms. These have been
supported since OpenSSH 7.2 and are ...
There are three primary ways to keep an SSH session alive:
TCPKeepAlive - An empty ACK is periodically sent, preventing the TCP connection from naturally closing due to inactivity. This operates entirely on the TCP-level. It can only be spoofed with an MITM attack or an extremely advanced TCP-hijacking adversary.
ServerAliveInterval - A message is sent ...
As RubberStamp points out, this is covered in detail in stronger encryption for SSH keys but to summarize:
Look at the words in the first line, and the next one or two.
-----BEGIN RSA PRIVATE KEY-----
(several lines of base64)
-----END RSA PRIVATE KEY-----
(or similarly with DSA PRIVATE KEY or EC ...
The users key is used for authentication of the user only, similar to the optional client certificate in TLS (which includes HTTPS). Encryption is done with a key created using a key exchange algorithm like Diffie-Hellman but only after authorizing the server to protect against man in the middle attacks. Insofar is SSH similar to TLS.
For more information ...
There are a number of things you can do:
Set up a private key that uses a key-stretching algorithm to protect brute-forcing the passphrase.
Configure AllowUsers in sshd so only named accounts can gain access
Use fail2ban or fwknop to further prevent outside attacks (remember that CVE-2008-0166 caused Debian users to generate only one of 32,767 possible keys)...
Fallback DH groups are defined in source code here. The current group can be 2k or 4k. But it really depends on which version are you using (there were some changes recently).
Note the RFC 4419, which specifies:
Servers and clients SHOULD support groups with a modulus length of k
bits, where 1024 <= k <= 8192. The recommended values for min ...
How do I know when a rekey has happened? Should I check any logs, or any specific output? Running sshd in debug more (-d) does not show me anything related to rekeying.
It is printed only in debug mode, because it should not be a think you should care about. It should work out of the box as it is. But anyway, you can increase log level from your client ...
DH keys are used to achieve forward secrecy, they are unique for each session and ephemeral - there is no need and no way to pre-distribute them
client authentication keys (RSA) already have the requirement to be pre-distributed - by placing the client public key in the user's authorized_keys file on the server
server authentication keys can be ...
The following is from the OpenSSH 7.8 release notes, 2018-08-24. (http://www.openssh.com/txt/release-7.8)
This release includes a number of changes that may affect existing configurations:
ssh-keygen(1): write OpenSSH format private keys by default instead of using OpenSSL's PEM format. The OpenSSH format, supported in OpenSSH releases since 2014 and ...
You already quite understand how the public key cryptography works and how the client is authenticated to the server using public key authentication.
The same thing is needed on the other direction. Internet and computer networks are evil place and it is quite easy to redirect traffic, spoof DNS or somehow make you connect to evil host, which would like to ...
1- Can someone explain how to extract the actual public key from the the ssh key public key (removing all the extra stuff and leaving just the key)?
The format of public key is described as the part of known_hosts section of manual page for sshd:
keytype, base64-encoded key, comment.
So lets create a key to see what is there.
$ ssh-keygen -t ed25519 -f ...
TL;DR: use smart cards.
To prevent distributing the key to other persons you need to prevent that the user has read access to the key in the first place. The key is used in SSH for authentication. The authentication process involves cryptographic operations (signing) which need to have read access to the key. In order to protect the users key against ...