Tag Info

New answers tagged

3

Key strengths, and their equivalences, become meaningless when they reach the zone of "cannot be broken with existing and foreseeable technology", because there is no such thing as more secure than that. It is a common reflex to try to think of key sizes as providing some sort of security margin, but this kind of reasoning fails beyond some point. ...


0

My solution would be: The user innocent compiles THC-Hydra from source, then realises that he / she is missing a necessery lib and installs it (hence the sudo aptitude install libssh-2 on innocent-laptop). He / she then proceeds to use Hydra against naive's ssh roughly at 18:22:30 (as marked by the network configuration). The attack succeds at 18:50:29. ...


0

What follows is an interisting explenation of risks on a malicous SSH server but does nto awnser the question asked. On a Malicious SSH server in between you and a targeted machine you run the following (theoretical) risks First some definitions: ServA = The malicious SSH server with intend to cause harm to your target or to yuu. ServB = The Targeted ...


3

As noted in the accepted answer the signature is determined using the private key over various pieces of data: The value of 'signature' is a signature by the corresponding private key over the following data, in the following order: string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string ...


0

To answer your question, yes, you can share the host key on all the servers in your load balanced pool. Then, you do the host key verification once for the IP/DNS entry you are load balancing and it will log into any of the pool members from then on without asking you again. Before I go any further, for those wondering why you would do this. This may not be ...


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. ...


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 ...


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: ...


0

You can convert your SSH public key (id_rsa.pub) to a PEM public key file with the following Python script (cribbed from this blog post): #!/usr/bin/python # usage: sshpub2pem.py id_rsa.pub > id_rsa.pub.pem import sys, base64, struct from pyasn1.type import univ from pyasn1.codec.der import encoder as der_encoder keydata = base64.b64decode( ...


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 ...


0

Does the visual fingerprint uniquely identify a server's key? No; the "visual host key" algorithm does not preserve enough information to give each key a 100%-guaranteed-unique image. But neither does a more traditional fingerprint. ECDSA keys like yours have 256 bits. RSA keys have 2048. But if you count the hex digits in your image, you come up with ...


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 ...


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.


0

Well besides the sudo answer (which is really clever btw), another solution is a restricted shell. In this case you would have to write one. In this case the only commands you need to accept are "ssh <hostname>" and "exit" so it's not so hard. I'm really only posting this for completeness, but the general technique is valuable in other contexts.


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 ...


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.


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 ...


0

I would Propose a different work flow for security: Have a Key based SSH login process. (so no passwords for that) Have a automated (key-based) auto mounting chroot (which is the encrypted container) and only receives the password from the SSH connection (password only leaves the client machine to unlock the ecryptfs and is protected in transit by ssh. and ...


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 ...


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 ...


0

As others have already noted, changing the default SSH port doesn't gain you much from a security perspective. However, it can still be of advantage to do so if you intend to connect to the machine from a network where the administrators have locked down port 22. (Many schools, workplaces, and free WiFi hotspots block all outgoing traffic except that on ...


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 ...



Top 50 recent answers are included