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.
Related
I am trying to understand if SSH can be set up to work the way HTTPS works - there are 'authorities' that store public keys mapped to a specific company together with other information that can be useful (like date, signature, etc.). In other words it's a certificate that can be checked by clients (most often browsers) and verified that this is really the company this web site represents. This is essential to prevent the middle-man-attack or a fake web page looking exactly like the original one.
I am new to SSH and I am trying to understand if there is a similar mechanism for certificates check - I looked everywhere and I don't find an answer to this. What bothers me is when you have a server set up by another person (maybe you don't believe this person) and you want to ssh to this server for a first time (make it a known host for future connections) you can't be absolutely sure that there is no middle-man because you do not check the certificate against an authority (this can be just your company cert authority)? The public key of the ssh server that your ssh client receives is unknown and can not be verified. How can I be sure this is really the server I want to connect to?
Does this make any sense or I am just missing something ?
Thanks in advance!
I understand your confusion.
Let me try to clarify, maybe it helps.
To establish trust that the remote host that you login to is indeed the host you expect, SSH provides you the mechanism of the host key fingerprint verification.
How do you know what the host key should be before you have ever logged in? Well, this appears to be a problem that can only be solved out of band.
SSH has no way of knowing, whether the host you login to is the one you think it is - this is exactly the reason it asks you to confirm whether the fingerprint of the host matches what you expected.
As a consequence, you need to obtain the correct host key fingerprint from the person or entity that has set up the host for you. In other words: you need to trust that the person has fulfilled the following three premises:
Set up the host correctly, and
Provided you with the correct host key, and
Ensured that nobody else has access to the host’s private key.
If these three premises are established, you can verify in the future, whether you are indeed connecting to the correct host as SSH is able to validate whether the remote host indeed is in possession of the private key corresponding to the host fingerprint.
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.
Our current infrastructure uses ssh keys for passwordless login to our Linux servers.
As our infrastructure grows, managing these authorised keys is getting harder.
As we also have an Active Directory (AD) server, I would like to authenticate the users over ssh using this mechanism, but maintain the passwordless nature of ssh keys.
Is it possible to authenticate the users over ssh without password, using some AD mechanism?
This is usually done via SSH key certificates in order to keep the password-less nature and at the same time have a Central Authority that can be trusted to generate new certificates for each account.
LDAP/Active directory use on login is not advised - apart from having to use passwords, it also becomes a single point of failure for access to any system it manages.
See RedHat documentation on how to do this and also Facebook's good write up on their use of certificate authentication with SSH.
Option 1
This is a good article explaining how to do this.
Storing SSH keys in Active Directory for easy deployment
Basically, it will allow people to post their public keys to your Active Directory and then you can set up a cron script on your servers to fetch a copy of the public keys every 5 minutes or so.
Option 2
You could also use a file server that has all your keys and get each server to fetch from there using a cron script. Obviously, you need a way to verify each key's authenticity especially if you are using FTP or some other insecure protocol. This could be achieved using GPG. You could have a company master GPG key that signs all the employee keys.
Personally, I like option 2 the best because I think it is more secure, but either method should work. Hope this helps!
My approach would be to reduce the problem to an already solved one by
Use active directory to authenticate without password and establish an HTTPS connection using Kerberos. The Dzone Tutorial Configuring Tomcat 7 Single Sign-on with SPNEGO might be a good starting point for that approach.
Wrap SSH into the https-protocol like, see section Wrapping SSH in HTTP(S) at https://unix.stackexchange.com/questions/190490/how-to-use-ssh-over-http-or-https
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.
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.