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.
Related
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.
I am trying to connect to Unix server from WinSCP commandline for the first time.
It closes with the the following error:
The server's host key was not found in the cache. You have no guarantee that the
server is the computer you think it is.
The server's rsa2 key fingerprint is:
ssh-rsa 1024 42:9e:c7:f4:7f:8b:50:10:6a:06:04:b1:d4:f2:04:6d
If you trust this host, press Yes. To connect without adding host key to the cac
he, press No. To abandon the connection press Cancel.
In the WinSCP commandline, it does not ask for any input (Yes or No). It closes with Authentication failed. If I connect through the WinSCP tool, I'll get the same error. However, I'll be able to press YES.
I also know that If I add -hostkey switch in the command line, I'll be able to connect. But, I don't want pass hostkey in my batch script as I will be connecting to various servers. So, my requirement is to pass "YES" input from the commandline in case of this error. Can someone help?
A host key fingerprint verification is a crucial step in securing your SSH connection. Even if you are using a set of sessions with your script, it does not excuse you. The fingerprint should be part of a set of information you have for each of the sessions (in addition to a hostname, an username and a password).
Skipping the fingerprint verification means that you lose any security and there's no point using an SSH/SFTP anymore.
Anyway, if you do not care about a security, you can use the -hostkey=* switch to unconditionally accept any host key.
Further references:
Where do I get SSH host key fingerprint to authorize the server?
Verifying the host key
I have several raspberry pi devices, and I want to link them to one web application securely with ssl in public key infrastructure. and the raspberry pi should keep a credential key inside its memory for the device authentication. But I have two issues 1. who(raspberry pi or server) should generate the key pairs 2. who keeps the private key.
so for the first issue,I 'd like to follow the example of Amazon EC2 service. where the server instance generates the key pairs, and server keeps the public key and send the private key to user. One personal reason is, I want a group of raspberry pi to share the same key if they want to connect to one particular service. so each particular service would generate a key pair and share it with a group of devices linked to the service. if we allows each device to generate a key pair for the service, it is hard for the server to control the access, right?
for the second issue, as what aws does, the private key is send to the user,that also means we have to ensure the private key given to the user/device securely. But I am wondering if it is a threat to issue the same private key to many devices, that if one device's key is stolen, the whole service on the server side is compromised. in that reason, is it even better to give these devices a public key than a private key?
please correct me if my guess is wrong based on my limited security knowledge
It would be best & the most secure if you wrote a short script that could generate a keypair on each raspberry pi and then copied the public key to the server (e.g. scp). This way your private keys are on the pi's in the way the system is intended for.
It doesn't matter who generates the key's per say, just how they're transported. You can think of it as it doesn't matter if Lowes or Home depot makes the keys, just that everyone gets the correct key transported to them without getting them copied along the way. You always want your private keys to be kept secret, but it doesn't matter if a public key is intercepted.
The most secure thing is to say, client1, client2, and client3 are authorized to talk to the server. In other words, the server says, I know these three clients individually and can decide later on if one of them has gone AWOL and stop talking to them until they present a new proper key.
It would be a slight inconvenience to not copy the same keys across all devices, but it will save you headaches down the road if security is compromised for any reason, will keep your system from grinding to a halt while you figure out what went wrong, and is the proper thing to do.
(Case 2) But, it depends on how your devices are talking to each other. If it is through ssh, the above is what you would want to do. If you are using ssl and https just to make sure that the end user on a pi knows that they are, in fact, connected to the server, then you would have a private key on the server and authenticate the public ssl certificate on all of your pi's via your browser or whatever. It doesn't matter if any pi's are compromised in this regard, since all your ssl certificate is doing is telling the pi's that they are, in fact, talking to the server in authority. Your only secret key to be worried about would then be protected the server itself (don't share this with your pi's).
Ultimately it depends on who needs to be authenticated. If people need to know that the server is the real server, then case 2 would apply. If the server needs to know that its' clients really are who they say they are, case 1 applies.
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.
I am using wireshark to intercept SSL traffic that is being sent from my machine. Because it is encrypted on my machine, the private key for the connection has to be stored there... correct?
Is there an application that will just show my the private keys. I guess it would kind of be a security vulnribility if it were easy though.
correct me if I am wrong, but because I encrypt out going connections with the servers public key, and decrypt incoming with my private key, I can only decrypt incoming connections... correct?
You're confusing several things here.
You don't necessarily have a private key at all in a client;
an SSL server practically always has a private key; but
SSL is not encrypted with public/private keys, it is encrypted with a symmetric session key which is generated for the session using the algorithm defined in RFC 2246.
As pointed out by EJP, this is only relevant if you're running a server, not a client.
If running a server, the location and format of the key used is detailed in the specific server's configuration. Some servers also include a procedure for exporting this key, which is inside a container or keystore.
Note also that even if you do obtain the private key, certain SSL cipher suites- notably those using the Diffie-Hellman key exchange mechanism - will prevent Wireshark from decrypting the traffic.