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. 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's password ...
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 ...
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 ...
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 ...
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 ...
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 ...
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 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
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 ...
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 ...
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> /...
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)...
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-----
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 ...
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 ...
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
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 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 ...
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 ...
SSH actually requires you to configure different keys for different users.
Each user account on the destination machine has its own ~/.ssh/authorized_keys (doesn't necessarily have to have, it might not exist).
Let's assume you have server and client.
server has users set up as follows:
Considering your explanation:
I'm not worried about them seeing the contents of my GitHub repository - I'm concerned about them being about to use the private key to impersonate me and wipe our repo or clone other private repositories that aren't already copied onto the server.
You may consider using GitHub feature called read-only deploy key.
In a non-...
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 ...