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)
so: YES! make it the new default, backup old keys, generate new keys! (upgrade!)
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.
what is really really usefull, is running this script (on server AND client) to debug possible problems during ssh connections.
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 email@example.com:~/ firstname.lastname@example.org'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 email@example.com # 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
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
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).”
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
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/