Instead of exchanging ftp/sftp credentials over email is it safer to to exchange a systems ssh-keys over email? If a person didnt have the physical ssh private file, would a hacker be able to gain access to the server by just knowing the public ssh-key string?
1
-
Note that sftp uses ssh as the underlying encryption protocol, so you can use ssh key pair to authenticate to an sftp server.– Lie RyanSep 9, 2015 at 1:23
Add a comment
|
3 Answers
The point of a public key cryptosystem is that the public key can be publicised far and wide without compromising the security of the system. So, no, if a hacker is able to intercept the public keys of the server, it gains them no benefit in attempting to gain access to the system.
As already mentioned in wombles answer you are safe if an attacker intercepts the key. That is the purpose of asymmetric cryptography.
But if the attacker is not only able to intercept the key, but also able to manipulate your communication channel he could replace the sent public key by its own key and get access to your systems. Its generally referred to as the authentication problem.
If you are paranoid and know the voice of the person, that sends you the key, you should also verify the key fingerprint on phone, as voice communication is much harder to manipulate than emails.
-
2
Yes, it's completely safe to share the server's public key, which is used for identification of the server, and man in the middle protection. Once you have 'accepted' the public key, your client will remember it, and warn you if it changes. (Which it would, in the case of a Man-in-the-Middle attack.)
Normally one could go further, and publish the key's fingerprint in DNS, according to rfc4255: http://www.ietf.org/rfc/rfc4255.txt
This allows the client to retrieve the fingerprint of the key, before actually connecting to the ssh daemon to receive the public key over port 22.
If the fingerprint matches the public key provided by the server; the connection will continue.
Here's some basic instructions for enforcing this. https://simon.butcher.name/archives/2011/01/16/SSH-key-fingerprints-in-DNS
As for the private keys, either generated by you or by your client, these should be kept absolutely secret, and be stored with a strong passphrase.
In general, I'd recommend disabling passwords over SSH with the /etc/ssh/sshd_config option:
PasswordAuthentication no
This will only allow clients with private keys listed in ~/.ssh/authorized_keys to connect. Yes, you can still use passwords at the sudo/su prompt, it simply won't let you log in with a username and password over SSH. A Private key is required.
I'd recommend stopping by correcthorsebatterystaple dot net if you're having trouble thinking of a good passphrase.
(And yes, a passphrase may contain spaces, something like "Noble Sister Protection" can be easy to remember and still carry enough entropy for sufficient protection -- see XKCD comic #936 entitled "Password Strength".)
When a private key has a passphrase associated, the .ppk or id_rsa file the client keeps is encrypted. The general idea is, you (the server admin) will never know this password/passphrase used to encrypt the client's key. Once the client unlocks/decrypts the key to present it to you (the server) as a math problem, authentication proceeds. There is no way to recover a client's passphrase from the server, at all, ever (unless they are foolish enough to upload their private key -- don't do that! Use SSH Agent forwarding, or putty's pageant.exe key agent on windows.)
