Tag Info

Hot answers tagged

10

Not sure why you're using AWS-created keys. The "Network & Security / Key Pairs" screen also has an "Import key pair" button, I've successfully used it. When you add a new team member who might be standing up new images, get his public key, import it. Keep a copy of your standard "authorized_keys" file, with one or more public key per person, on a ...


6

No, having keys for your root user does not impact your security profile. It is wise though to disable root login in ssh and NOT have an authorized_keys in your /root/.ssh/ folder. However. I got the feeling your going about this the wrong way. Personally, I would not use the root user in this manner (but a system user like www-data) and make several ...


4

1: Use hardware tokens, like a Yubikey configured for challenge-response based authentication. Or smartcards. You load up the key on them all and hand them out. They're designed to keep the secrets secret. 2: Stop using a single key, start using one keypair per user for accountability and practical revocability.


2

I don't think this should be an issue - using a single key pair to access many servers is perfectly fine and most of the world works that way. Its important to understand, as @Tom Leek mentioned, that the private part of the key - which must stay secret - is only stored on your single machine and is never transfered out of it. So even if one of the servers ...


2

The most common reason for this is that you are connected to an enterprise network that has active proxying, data loss prevention, filtering or similar. In order to do that for the increasing number of encrypted sessions, "clever" security devices perform a man-in-the-middle attack on your connection by replacing the normal certificate with their own. So now ...


2

WARNING: Creativity ahead, which is often bad for security (at least without thorough review). This sounds like a case in which an SSH agent could be useful. An SSH agent provides a socket interface over which SSH clients can ask the agent to perform key operations for them, which enables the following common uses: You can have the long-running agent ...


2

After re-reading all this, I insist : having root access granted to many users directly is generally a not so good idea. Use sudo is the recommended way (you could even run su, with group restriction). Why not use Un*x group original behaviour? For each user, add a specific account ( you could manage user account replication by using LDAP, NIS or even ...


2

Very odd that the attacks came from secureserver.net Being a previous customer of GoDaddy in the past I have only seen that domain name used for mail services. Reference: https://login.secureserver.net/?app=wbe I would preform a whois on the offending ip and report the issue to tech support/abuse consultant. This information is located in the whois report. ...


2

That RSA key is for authentication, not for encryption! You should not use authentication key pairs for encryption (if you literally mean extracting the ssh key to store encrypted data, rather than to share the keypair with an X509 certificate); because the public and private operations or RSA commute. For example, if you use the same key for both: ...


1

If you're doing this to avoid entering passwords, then that implies that either you'll run an SSH agent on Production, or you'll keep an unencrypted private key there. If it's the latter, then the administrators of Production will have access to your development box. But if I'm reading between the lines correctly, you're using this approach as a workaround ...


1

Maybe a solution such as FreeIPA could help you. It provides a way to make sure that ssh keys are properly distributed as well as sudo profiles and authentication. Z.


1

Found the answer myself in RFC4253: Signatures are encoded as follows: string signature format identifier (as specified by the public key/certificate format) byte[n] signature blob in format specific encoding. The "ssh-dss" key format has the following specific encoding: string "ssh-dss" mpint p mpint q ...


1

As others said, putting SSH on a port other than 22 will make more unlikely to be hit with a random scan. You will be targetted if the attacker is trying to get your server, not any server. I have a server with ssh bound to a random high port. And I have a ssh honeypot on port 22, that will reply to any and every login attempt with a 'access denied' ...


1

This is something of a philosophical question: "is control X helpful?" And as the best answer pointed out, you should also consider "what are the costs (client support, doc exemptions, system support, monitoring support, and I'd throw in direct costs, licensing costs, etc) of control X?" Anything is helpful in certain contexts. It is a good idea to ask ...


1

In order to remove the cbc ciphers, Add or modify the "Ciphers" line in /etc/ssh/sshd_config as below: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,arcfour In order to remove HMAC MD5 Add or modify the MACs line in /etc/ssh/sshd_config as below : MACs hmac-sha1,hmac-ripemd160 Restart SSHD to apply the changes: service sshd restart


1

Host keys authenticate the server to you, your keys authenticate you to the server. The SSH Host Key provides a fingerprint that you can use to validate you're connecting to the server you think you are. You manually verify the public key fingerprint you're presented during your first connection, then you save it. For every connection after that, the ...



Only top voted, non community-wiki answers of a minimum length are eligible