I have the following set up:

1. server1 with sftp users: client1_user and client2_user
2. client1
3. client2

I have asked both client1 and client2 owners to generate and send me their public keys. I will add their ssh keys in their respective local user account on server1 .ssh/authorized

i have disabled password authentication and only allow key based.

they will login by passing their private key. this works as intended.

but what if they cannot create a key pair. Can i generate 2 key pair from any machine (even windows) and place the public into the authorized file (on server1) and email them the private keys? Is there any security related problems if I do this?

Yes.Only the risk of the key falling into "other" hands (f.e. yours, or anyone with access to the email etc).
More secure delivery of the key could be arranged (usb on a carrier pigeon or such) - probably depends if you're running a nuclear launch facility or a cat vid archive.

1 members found this post helpful.

Out of curiosity, why can't they generate a key pair?

Mail in transit is often scanned for authentication information like passwords or keys. I can't say how probable it is that your mails will go past such a scanner but it is possible. Scans are automatic. So when they hit, they hit quickly.

It's work but it is really worth the effort to have one key pair per user-server combination. As to getting the keys to the users with dud systems, I can think of several options:

If you can encrypt the mails containing the private keys, then that would be one option.

Another would be to use a real passphrase and contact the recipient out of band with the passphrase for the key.

Another option would be to give them one key, or better an SSH certificate, with an expiry date and then have them log in and download their real key. After that you can delete the temporary public key from their authorized_keys file. However, only recent versions of the OpenSSH server support expiry-date for the keys. Old ones can do the certs though.

1 members found this post helpful.

On my network, I generate the access keys.
I don't trust users to do it securely or correctly.

https://www.ssh.com/ssh/keygen/#sec-...Authentication

How do you actually get the right private keys on to the right client machines inside the right client user accounts?

I send it to them in a secure manner (usually compressed w\archive password) and as stated, out-of-band.
User key management is not my problem.

what usually follows is a parade of "what is a client-server relationship", how to "use" an ssh client, etc...

thanks to all especially to descendant_command and Turbocapitalist

Ok if i generate a key pair from windows; my private key has this one line at the end "Private-MAC:". Does this mean that i can only use this private key from the same MAC address it was generated from? or can i give this private key to a linux machine and they will be able to use it?

Whenever I have to send a password to a user I do that using WhatsApp. It has not happened yet that I had to send a private key, but I would use WhatsApp as well.

I agree that mail in transit is vulnerable, I simply do not use it for passwords. But is WhatsApp safe for that matter? It is said it is end-to-end encrypted that is why I trust it.

As I understand only NSA picks up WhatsApp, probably descrypts it. And then hackers get access to NSA, I know. But it sounds safer than e-mail. Safe enough?

jlinkels

Putty?

Private keys should never be "given out". See https://www.ssh.com/ssh/key/
and https://www.ssh.com/ssh/public-key-a...he-Private-Key
and https://www.linuxquestions.org/linux...ation_with_ssh

key.pub contents in correct ~/location on the "server" (as in "client-server", or the host the <user> needs a connection to)
Matching Private key in ~/.ssh/ for the <user> on their "client" machine.

No idea for "Private-MAC" since we have no actionable data like what OS/platform made the thing and what utility that may involve. I've seen it and I believe openssh-server v6.6 (possibly) complained about the "Private-MAC" element (but did allow me to connect), so I removed that element of the output, as I have other layers to inhibit access to my servers.
"Private-MAC" is on some of my putty ssh keys that I had to "import" on putty to use as a key.ppk that putty requires.

See also Best Practice: ”separate ssh-key per host and user“ vs. ”one ssh-key for all hosts“
and
https://www.networkworld.com/article...-software.html

1 members found this post helpful.

That is an interesting discussion. Down in the section with no upvotes, "Here are a few additional considerations", it brings up the point about a potential problem with using multiple keys and an agent. What happens with multiple keys in an agent is when trying to connect, the agent will respond with its keys in more or less random order and if you hit the failed login limit before hitting the right key, you can't get in.

That is easily fixed by using IdentitiesOnly and IdentityFile in the ~/.ssh/config file for the respective remote hosts.

One should be using the ~/.ssh/config file regularly anyway. See "man ssh_config" for all the options. But because the rules get applied as the are found in the file, the rules go in order of more specific to more general. So the most specific rules go first and the most general ones go at the end of the file.

The meat and potatoes of that one is unfortunately in a bitmapped image which may or may not get noticed properly. Unfortunately, the source document NISTIR 7966: Security of Interactive and Automated Access Management Using Secure Shell (SSH) is a PDF so that is also of limited accessibility. However, it is very good to read through the whole document despite it being about 50 pages of content.

Some of the recommendations though make assumptions about scale and are really best implemented in organizations above a certain size. Others are good regardless.

Unfortunately on networks where Windows units are allowed, there are problems following best practices or remaining in any way secure. That seems to be one of the issues here.

MAC here stands for Message authentication code. I can't find it in the putty docs, but the source says:

https://git.tartarus.org/?p=simon/pu...3;hb=HEAD#l433

2 members found this post helpful.

thank you for your time finding out for me. Really appreciate it. Man are they running our of unique acronyms or what.