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 ...
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 ...
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 ...
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 ...
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 ...
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
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 ...
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 ...
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> /...
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
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 ...
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 ...
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 ...
The key difference here (no pun intended) is that the key includes a significant amount of entropy (i.e. it is random). Passwords are often quite terrible, commonly having under 30 bits of entropy. 30 bits is easily brute-forceable, so password hashes are designed to be slow (you specified salted SHA512, but you omitted the number of rounds), making the ...
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 ...
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 ...
On a general basis, you should not forward X11 display from untrusted environments to your local environment. X11 is an old technology which was not conceived with security in mind from the beginning, on the contrary it was designed to allow every application to communicate with each other.
Was does "communicate" mean? As you said, it could grasp you ...
As pointed out in the comments, there is no other risk then using normal ssh with password.
This means that from the client you need to go through the common check of hostkey or fingerprint and then everything (passwords, keys and all communication) is encrypted.
You can even have a look into ssh-copy-id, since it is just a simple shell script doing the "...
Let's start with what we know:
You have a process running in an isolated environment
You want that process to communicate with the logging system
It follows therefore that you need to provide some way to route the communication from your process to the logging daemon. There's two ways to do this: Unix sockets or TCP sockets.
To the application, Unix ...
It should be as resistant as a good passphrase (obligatory quote of xkcd, even though it does not relate to offline attacks (but another one does))).
The encryption mechanism used by ssh-keygen is slow - which is good. Since the answer will be changing with time as computational capacities increase, make it 25 characters long and you will be good to go for ...