Why ssh-copy-id copies public key when adding it to authorized_keys seems enough? - ssh

A colleague of mine told me he could SSH into a server where his key is only listed in authorized_keys. I was surprised and wondered why ssh-copy-id copies the key to the server then ?

Because that is how you would let a client connect to the server via Public Key Authentication.
ssh-copy-id is a script that installs a public key on a remote machine via ssh. Basically what it does is append the public key to the remote machine's ~/.ssh/authorized_keys (see ssh-copy-id man page for more details). It can be useful especially if you do not have physical access to the machine.
But of course, since the public key you would like to use wouldn't be installed on the target server yet, you would have to log in with an already available authentication method like login password, preventing potential malicious users from adding their own public key.

Related

install key using ssh-copy-id through forwarded ssh-agent

So I'm using ssh-agent on my host and we use vagrant, virtualbox and other normal tools to setup our environment. At one point, we need to provision new machines (we build appliances) and push our key into that appliance. So far, we had been unprotecting our keys and just copying our id_rsa(.pub)? on the virtual machine. It suited us!
Recently, I started using ssh-agent on my main machine to host my keys with a password (much better obviously) but from time to time, I seem to have problems running ssh-copy-id to copy my id towards the appliance.
Most of the time, I have to just copy my protected key files to the vm and then it works but I'm sure i was able at one point to leave the virtual machine clean from any ssh keys and still use ssh-copy-id to copy my ssh-agent provided identity through the vm. It doesn't seem to be working half of the time.
Am I crazy? What could be the root cause of this? How to I solve this problem to ensure that my SSH protected id is forwarded only from my local agent into the vm and into any other appliance properly?

Is serverpilot making a ssh connection without ssh key, despite password authentication is disabled?

Following the basic instructions to secure the server, I took the following steps:
added a ssh-key
disabled password authentication
disabled rootlogin
created another user with sudo
As an another user I've no problem in accessing my server through terminal.
Now, I've also added my server on serverpilot [serverpilot.io], and my curiosity lies in the fact that without ssh key the server can't be accessed then how the user serverpilot is accessing the server with password and without sshkey which is not shared with serverpilot.

Passwordless login to a specific directory by SSH

I know how to login without password to remote host by SSH. But that way I can access to all folder to remote host. Is there any way to give access to only specific folders by SSH?
I used ssh-keygen to generate public-private key pairs and then added public key to ~/.ssh/authorized_keys in remote server.
You want sftponly. It is a little involved to set up, but I have it running for two dozen sftp only clients. It performs a chroot when the user connects and it prevents ssh access -- thus the name.
https://www.allthingsdigital.nl/2013/05/12/setting-up-an-sftp-only-account-with-openssh/
Note that you can't allow the user to have write access in the dir they log into, but you can bind mount any other directories and give them r/w access to them.

Granting guest access to server with key based SSH login

Quite simple: How can guest SSH access to a server be granted to multiple users who will share the same 'guest' login?
The server has only RSA key access (no password login) and this works fine for the normal case where the public keys of single users are copied to authorized_keys on the remote server. What I'm looking for is guest access as user 'guest', the problem is the keys - I don't want to have to install keys from all my clients, rather give them a key to use - would this be the private 'guest' key? How does this work?
Clients will be connecting from Linux, and Windows using Putty.
I dont see a problem here.
In your setup you treat all connecting people as a single person. Thus they all can use the same key, in this case you have to hand out the private key to all of them.
However that is a BIG security risk. Once that key is given out (happens with lots of unexperienced users) you have to replace the keys for ALL people. That does not sound very good.
All you have to do is reverse the procedure.
Create the RSA keys at server side. And then copy public key to the authorized_keys file and take private key at client side.
So now multiple clients can do ssh to the server using this private key.

How do two machines authenticate over an SSH connection?

I always use ssh in putty to connect a remote server. As I know, ssh is based on public/private key mechanism, is it?
Does that mean the client will receive a public key first time when it connects to the server and then use the public key to continue with following communication?
Thanks.
Do you mean for authentication, or for encryption?
For authentication, Section 5.5.1 here covers it:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch05_05.htm#ch05-46136.html
In general, you create the key pair and get them there through other means.
If you mean for the encryption, try section 3.9.1.3 here:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_09.htm#ch03-65213.html
There are two parts where public/private key come into play -- session initialization and (optionally) user authentication.
In session initialization, the host public and private keys are used to set up the encrypted connection, but are not used to encrypt the connection itself. Instead, the initial set up is used to securely generate a unique session key that is used to encrypt the connection. The host public/private keys are generated and installed on the server.
While connecting, your ssh client (PuTTY in this case) will verify that the host key is what it remembers from the last time you connected. (If they are different, then somebody might be snooping on your connection!) This is why PuTTY asks you to confirm the hash of the host key the first time you connect -- it doesn't have a record of what the key is supposed to be, so it asks you to verify. If you tell PuTTY to confirm and save, then PuTTY will save the hash of the host key in the registry for future connections.
In user authentication, the user public and private keys are used to allow access to the server. The public key is installed for the user on the server. The server can then use that key to issue a challenge to the client that can only be answered correctly by using the user's private key. The user generates the public/private keys him/herself (e.g. with ssh-keygen).
For PuTTY, you can generate your own public and private key using the PuTTYgen utility (this is the PuTTY equivalent to ssh-keygen). It's up to you how you want to get the public key installed on the server. Then, run Pageant (a little app that sits in your notification area) and add your private key. If you set a passphrase on your private key, then Pageant will prompt you to enter it. Pageant, while running, will then work with PuTTY (or pscp, psftp, etc.) to make use of your private key.
This is a gross simplification of the processes involved; see James' answer for links to details.