Ssh-keygen Automate

[Kum Filteau]

Iwould like to make an automated script that calls ssh-keygen and creates some pub/private keypairs that I will use later on. In principle everything works fine with....

ssh-keygen -b 2048 -t rsa -f /tmp/sshkey -q

...except that it asks me for the passphrase that would encrypt the keys. This make -at present- the automation difficult.

I could provide a passphrase via the command line argument -N thepassphrase, so to keep the prompt from appearing.Still I do not even desire to have the keys -additionally secured by encryption- and want the keypairs to be plaintext.

Please do not start preaching about or lecture me to thepro and cons of the "missing passphrase", I am aware of that.In the interactive form (not as a script) the user can simply hit [ENTER] twice and the key will be saved as plaintext. This is what I want to achieve in a script like this:

Is there a way that I can bypass this and get the new host to be already known to the client machine, maybe by using a public key that's already baked into the virtual machine image ? I'd really like to avoid having to use Expect or whatever to answer the interactive prompt if I can.

The above will do the trick to add a host, ONLY if it has not yet been added. It is also not concurrency safe; you must not execute the snippet on the same origin machine more than once at the same time, as the tmp_hosts file can get clobbered, ultimately leading to the known_hosts file becoming bloated...

Do not use the old value StrictHostKeyChecking=no which never checks the authenticity of the server at all. Though the meaning of StrictHostKeyChecking=no is planned to be flipped later.

To do this properly, what you really want to do is collect the host public keys of the VMs as you create them and drop them into a file in known_hosts format. You can then use the -o GlobalKnownHostsFile=..., pointing to that file, to ensure that you're connecting to the host you believe you should be connecting to. How you do this depends on how you're setting up the virtual machines, however, but reading it off the virtual filesystem, if possible, or even getting the host to print the contents of /etc/ssh/ssh_host_rsa_key.pub during configuration may do the trick.

That said, this may not be worthwhile, depending on what sort of environment you're working in and who your anticipated adversaries are. Doing a simple "store on first connect" (via a scan or simply during the first "real" connection) as described in several other answers above may be considerably easier and still provide some modicum of security. However, if you do this I strongly suggest you change the user known hosts file (-o UserKnownHostsFile=...) to a file specificfor this particular test installation; this will avoid polluting your personal known hosts file with test information and make it easy to clean up the now useless public keys when you delete your VMs.

The script will loop over the names sites and modify the .ssh/config and .ssh/known_hosts file and do ssh-copy-id on request - for the last feature just the let the ssh test calls fail e.g. by hitting enter 3 times on the password request.

That 'fingerprint' is just a string shortened with a one way algorithm for our human convenience at the risk of more than one string resolving into the same fingerprint. It happens, they are called collisions.

At this point we manually are as vulnerable as automatically-- the strings match, we have the base data that creates the fingerprint, and we could ask for that base data (preventing collisions) in the future.

Thanks for sticking with me, here you go. I'm adding the bitbucket RSA key so that I can interact with my git repositories there in a non-interactive way as part of a CI workflow, but whatever you do what you want.

I saw so many stack overflow posts telling you to programmatically add the key blindly without any kind of checking. The more you check the key from different machines on different networks, the more trust you can have that the host is the one it says it is-- and that is the best you can hope from this layer of security.

Don't do either of the above things, please. You're given the opportunity to increase your chances of avoiding someone eavesdropping on your data transfers via a man in the middle attack-- take that opportunity. The difference is literally verifying that the RSA key you have is the one of the bona fide server and now you know how to get that information to compare them so you can trust the connection. Just remember more comparisons from different computers & networks will usually increase your ability to trust the connection.

This answer from StackOverflow has a better more correct answer. You must obtain the .pub file from a trusted source -- your system bootstrapper should call home and provide the file to a management system.

To automatically accept and memorize the fingerprint on never-before-seen remote git server, e.g. when executing git clone [email protected], you can leverage git's GIT_SSH_COMMAND together with ssh's -o StrictHostKeyChecking=accept-new:

Modern versions of SSH support certificate authorities, much like the ones used for SSL/TLS which secure your everyday web browsing. This allows you to bypass the Trust On First Use mechanism, as trust is already established by the CA. This works for both users (authorized keys) and hosts (known hosts).

Note this will complicate the process by which you bring up the VMs, as you will need all systems configured to trust the CA, and will need to have your CA sign the host keys for the VMs before you can use it to skip TOFU.

Now compare the pictures, are they similar? Congratulations type "yes" on your client host to automatically add to known_hosts.Are they different? Might be a MITM attack, or you just might be sloppy.This is an OK solution if you just have password access. Let's hope nobody has your password.

If you are in the the same physical location. Grab a new router, a switch and create a local-network that is not connected to the internet or any other unknown network.Here you can use StrictHostKeyChecking=no as much as you please no MITM worries.Same goes for Virtual Machines that you run directly on your workstation in an isolated network. Don't need to worry about MITM attacks if you control the physical network layer.

Consider buying a KVM-switch, use HPE iLO, IPMI or even Pi-KVM if your server supports it. But even then, these services should be on an isolated network as well. You can also use Intel-ME on laptops or workstations, but that is a whole other can of worms.

Copy your servers key fingerprint to an USB-stick, go back to your client and add the fingerprint manually to known_hosts from the USB-stick. It's elaborate, but you will be able to sleep at night. You can even automate this somewhat with a script.If you want to be ber-clever and impress the arrogant minion above you, automate this with "Rubber Ducky" or alike. But don't be clever. Someones "cleverness" brought us here in the first place.

If you don't have access to the servers location. Call a trusted friend over the phone and ask him to verify the fingerprint before you add it to known_hosts. But often if you don't have physical access, you are probably working for a company that already has secure solutions for this kind of situation. If not, consider changing jobs, or be a smarty and offer your boss a better solution in exchange for a raise. (remember to mention the word "Ransomware" at least 5 times during that conversation).

If all of the above is not an option for you. And you desperately want to connect to an unknown machine somewhere on the internet while using an unencrypted proxy chain. You should reconsider your life choices. Or you might just be the man in the middle.

I'm creating a fabric 2.5 script to deploy a website on a new site. At one point, it will create a ssh key, and add the public key to gitlab using it's api. Then, it will clone a repo (containing the website source code).The clone command failed in the script, and when I went on the server and manually launched the command I had the The authenticity of host 'host.com ()' can't be established. Are you sure you want to continue connecting (yes/no)? prompt.

At first my solution was to search how to auto-accept it, but for security concern I added the pty=True arg in the c.run("command") function, and I was given access to the error during the execution of my script.

While SSH keys are standard, and more frequently used, in Unix and Linux environments, they are also used in Windows systems. Read on for an overview of SSH key best practices covering SSH security and authentication, how SSH keys work, risks and benefits to consider with SSH keys, and how to manage SSH keys.

The Secure Shell, and the public-key cryptography (an encryption schema using two keys: one public, one private) SSH keys use, is designed to provide strong, encrypted verification and communication between the user and a remote computer.

SSH technology is based on the client-server model and provides an ideal way to access remote devices over unsecured networks, like the Internet. The technology is typically used by administrators for several functions including:

Like many other modern authentication systems, the next generation of SSH authorization solutions seems to be evolving around the use of certificates. This alternative approach iterates on the SSH key workflows, adding centralized key generation and revocation. Some challenges with this approach are that it is not supported by all SSH endpoints and requires other internal infrastructure, like Certificate Authorities and automated workflows, for access.

While many types of SSH keys (RSA, DSA, ECDSA, ed25519) exist, RSA remains the most common and provides the broadest system compatibility. The more modern elliptical curve variants of RSA keys are gaining in adoption.

IT teams routinely use SSH keys to automate secure access to servers, bypassing the need to manually enter log-in credentials. The SSH network protocol encrypts all traffic between the client and the server while it is in transit. This means anyone eavesdropping on the traffic, such as by packet sniffing, would not be able to improperly access and decrypt transmitted data.

3a8082e126