update: 2021-08:

it is ALWAYS a good idea to use ssh -v for enhanced debugging-output-info messages.

SSH might use one of the following algorithms:

  • 🚨 DSA: It’s unsafe and even no longer supported since OpenSSH version 7, you need to upgrade it!
  • ⚠️ RSA: It depends on key size. If it has 3072 or 4096-bit length (or better 8192Bit), then you’re good. Less than that, you probably want to upgrade it. The 1024-bit length is even considered unsafe.
  • 👀 ECDSA: It depends on how well your machine can generate a random number that will be used to create a signature. There’s also a trustworthiness concern on the NIST curves that being used by ECDSA.
  • Ed25519: It’s the most recommended public-key algorithm available today! (src)

    • “It is designed to be faster than existing digital signature schemes without sacrificing security.” (src: wiki)

is more secure?

“ECDSA: The elliptic-curve (EC)DSA algorithm is supposed to help us combat these quantum computational attacks, while generating keys with significantly smaller key size without compromising the level of security.” (src)

“The book Practical Cryptography With Go suggests that ED25519 keys are more secure and performant than RSA keys.” (src)

so: YES! make it the new default, backup old keys, generate new keys! (upgrade!)

https://security.stackexchange.com/questions/187611/is-ed25519-still-secure-despite-the-fault-attack-published-in-2017

here are the details/the paper: ed25519-20110926.pdf

so either use RSA with a keysize x > 2048 Bits (like 8192Bits) or go for ED25519, which is faster, so probably the better mode.

it is assumed that the user has setup public-private-key-authentication and tested its workings and tightened security to only allow public-private key auth of specific non-root users.

giving a passphrase seems like a good idea, because it will protect your key (if passphrase is sufficiently strong) if it get’s stolen.

So even if somebody manages to hack into the user’s client and steal the private ssh-key – it won’t be usable without the password (unless even that passphrase is keytroke captured).

downside of pass-phrases: can’t (well) automate processess that use ssh for backup purposes such as rsync every monday at 00:00 o’clock this folder to this server, if a passphrase is in use.

it-security seems to always be to find a good balance between conveniance and security

it is conveniant to give everybody access to everything… but in the end you will have some evil ransomeware asking for money to restore your files.

physical security: could do it like this, keep your ssh key on an (truecrypt-encrypted? 😀 (not 100% plausible denyability… (they can tell there is something on the stick besides music, but atleast encrypted) stick that the user wears like a neckless?

add the same username to client and server

as said the same user needs to exist on client and server

# add user (Debian/Ubuntu, Fedora/RedHat/CentOS7, Suse12)
# and create hom directory
useradd -m username;

# assign password
passwd username;

# debian uses sh per default
# change default loginshell of user to bash
usermod -s /bin/bash username;
# become that user
# (so keys will automatically be saved for that user under .ssh)
su - username

is there any key-size-limit?

no. but the problem is: the longer the keys, the slower (cpu heavy) becomes the encryption/slowing down the connection or file transfer.

8192Bits (8*1024) have 16384Bits (16*1024) and been tested and should work.

uname -a
Linux debian 3.16.0-4-686-pae #1 SMP Debian 3.16.39-1+deb8u2 (2017-03-07) i686 GNU/Linux
ssh -V
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016

# generate a strong key
# ed25519 has a fixed key-length
# so no need to define -b x amount of bits
ssh-keygen -t ed25519
# if for some reason the user wants to add a comment to the key
ssh-keygen -t ed25519 -C "comment goes here"

# (or if required, but worse = slower)
# generate a 8192it strong rsa key
ssh-keygen -t rsa -b 8192;

# read here if one is a cryptographer or mathematician and want to know more about the RSA algorithm
# in 2020 still safe if keys are long enough

# from the manpage:
# -b bits
# Specifies the number of bits in the key to create. For RSA keys, the minimum size is 768 bits and the default is 2048 bits. Generally, 2048
# bits is considered sufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2. For ECDSA keys, the -b flag determines the key
# length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits. Attempting to use bit lengths other than these three values
# for ECDSA keys will fail.
# ED25519 keys have a fixed length and the -b flag will be ignored.

# example output:
Generating public/private rsa key pair.
Enter file in which to save the key (~/.ssh/id_rsa): Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:CMaKLUUoJTqQEcc09tTv3N+RlWSX1NZBSiQqB340T30 user@suse
The key's randomart image is:
+---[RSA 8192]----+
|=OB .. . o oooo+=|
|*=.= o o = o..E=|
|+ . = + + . .+.o|
| = o . .= ..|
|o o .oS. o |
| . o . o |
| . . . |
| . . |
| |
+----[SHA256]-----+

# it has 99 lines
wc -l ~/.ssh/id_rsa
99 ~/.ssh/id_rsa;

# what about 1024*16 = 16384 ? - just in case dwave and the CIA get serous about quantum computing :-p

# generate a 16384Bit long-strong key?
ssh-keygen -t rsa -b 16384
# works just the same (takes waaaaaaay longer to be generate though)
# expect one cpu core to go 100% for the next 10 minutes :-D - the RAM usage is only 3.8MBytes

Enter file in which to save the key (~/.ssh/id_rsa):
~/.ssh/id_rsa already exists.
Overwrite (y/n)? y
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in ~/.ssh/id_rsa.
Your public key has been saved in ~/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:mXqdzMlbq+JMZ4ifZF3MIcaatHvRLkIL1w2UHEitqVo user@suse
The key's randomart image is:
+---[RSA 16384]---+
| ..+oo |
| .o+ |
| .o= . |
| .oO B . |
| ..S o * |
| E* X * |
| oo X & o |
| . B.* + . |
| .=.o.. |
+----[SHA256]-----+

# now double the size :-D
wc -l ~/.ssh/id_rsa
195 ~/.ssh/id_rsa;

# on server: start logging
tail -f /var/log/auth.log

# uploading key to home directory of user on test-server
scp -v ~/.ssh/id_rsa.pub user@172.20.0.12:~/
user@172.20.0.12's password:
id_rsa.pub 100% 2783 2.7KB/s 00:00

# switching over to ssh-server
# attaching public RSA 16384 key to authorized_keys
cat id_rsa.pub >> ./.ssh/authorized_keys;

# or if only one user connects to this server under this user
mv -v id_rsa.pub ./.ssh/authorized_keys
# when you are done testing key lengths
# on the client and server side you need to do
chown -R user: /home/user/.ssh
chmod -R 700 /home/user/.ssh
# server side only
# this is where the public key goes
chmod 600 /home/user/.ssh/authorized_keys

# switching over to ssh-client
# a simple
ssh -v user@172.20.0.12
# should get you logged into ssh server
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
No mail.
Last login: Fri May 5 12:13:53 2017 from 172.20.0.7
# works like a charm :)
user@debian:~$

one might want to secure ssh further by:

  • no root login
  • no password login (only public-private-key based login)
  • allow only certain users users to login

see: https://dwaves.de/2017/05/05/linux-bash-config-ssh-to-allow-only-login-from-specific-usersspecific-hosts-sshd-allowusers/

benchmarks with larger ssh keys

more cpu is needed – but in general probably bandwidth is the limiting factor if you operate over the internet.

# 4096Bits RSA key
scp 1gybe.testfile 172.20.0.12:
1gybe.testfile 100% 1024MB 41.0MB/s 00:25
[user@centos ~]$ scp 1gybe.testfile 172.20.0.12:
1gybe.testfile 100% 1024MB 41.0MB/s 00:25
[user@centos ~]$ scp 1gybe.testfile 172.20.0.12:
1gybe.testfile 100% 1024MB 41.0MB/s 00:25

scp 1gybe.testfile 172.20.0.12:
1gybe.testfile 100% 1024MB 36.6MB/s 00:28
user@suse:~> scp 1gybe.testfile 172.20.0.12:
1gybe.testfile 100% 1024MB 37.9MB/s 00:27
user@suse:~> scp 1gybe.testfile 172.20.0.12:
1gybe.testfile 100% 1024MB 37.9MB/s 00:27

manpage: ssh-keygen.man.txt

passphrase session-cache – ssh-agent

“ssh-agent is a program to hold private keys used for public key authentication (RSA, DSA, ECDSA, Ed25519).

ssh-agent is usually started in the beginning of an X-session or a login session, and all other windows or programs are started as clients to the ssh-agent program.

Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh(1).”

src: ssh-agent.man.txt

You can actually cache-per-session your passphrase with the ssh-agent.

it works like this:

# list all cached passphrases (none)
# The agent has no identities.
ssh-add -l

eval $(ssh-agent); # will setup environment variables
Agent pid 2349

ssh-agent; # gives some info about ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-cvnht9zt5ehE/agent.2359; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2360; export SSH_AGENT_PID;
echo Agent pid 2360;

ssh-add; # cache passphrase of current logged-in user 
Enter passphrase for ~/.ssh/id_rsa:

Identity added: ~/.ssh/id_rsa (~/.ssh/id_rsa)

ssh-add -l; # reports that one passphrase has been cached
8192 SHA256:5Co8zddjNGPr1dXrdOKR5bRv78KtD/Hnrn8Z9D/ocQk ~/.ssh/id_rsa (RSA)

user@suse12:~/.ssh> ssh debian8; # you should be able to automatically login, without beeing asked for a passphrase during your whole session, this also works in sub-shells until you completely log-off/out of your system

Links:

cool things to do with ssh: https://dwaves.de/2017/05/08/remote-desktop-gnu-linux-x11-forwarding-gui-output-run-process-on-server-while-graphical-output-is-on-client-ssh-x-encrypted-tunneling-of-graphical-output-of-programs-vnc-job-control/

ssh and security – https://linux-audit.com/audit-and-harden-your-ssh-configuration/

man pages:

ssh.man.txt

ssh_config.man.txt

admin