Tag Info

Hot answers tagged

96

Go with RSA. DSA is faster for signature generation but slower for validation, slower when encrypting but faster when decrypting and security can be considered equivalent compared to an RSA key of equal key length. That's the punch line, now some justification. The security of the RSA algorithm is based on the fact that factorization of large integers is ...


74

From what I heard earlier today, https/ssl flows correctly through your borders. You should hence check out Corkscrew. Similarly to netcat, it's used to wrap ssh in https to allow the use of https proxies. Another solution would be to use LSH which, by having a different signature than ssh, works from Iran as Siavash noted it in his message.


54

SSL and SSH both provide the cryptographic elements to build a tunnel for confidential data transport with checked integrity. For that part, they use similar techniques, and may suffer from the same kind of attacks, so they should provide similar security (i.e. good security) assuming they are both properly implemented. That both exist is a kind of NIH ...


45

The Internet is a wild and scary place, full of malcontents whose motives range from curiosity all the way to criminal enterprise. These unsavories are constantly scanning for computers running services they hope to exploit; usually the more common services such as SSH, HTTP, FTP, etc. The scans typically fall into one of two categories: Recon scans to see ...


36

My answer is that using public key pairs is a much wiser thing to do than using passwords or lists of passwords. I will focus on things that are not widely known about different forms of SSH authentication, and I see no other answers mentioning them. First of all, you must understand that user authentication is a different and separate process than the ...


33

Key based login is considered much more secure than password based logins when looking from the perspective of a brute-force attempt to gain access from a third party system: The chances to crack a key are effectively zero, while bad passwords are all too common. From the perspective of a compromised client system (your workstation), there won't be a ...


28

As per the SSH standard (RFC 4251 and subsequent), a DSA key will work everywhere. In practice, a RSA key will also work everywhere. ECDSA support is newer, so some old client or server may have trouble with ECDSA keys. ECDSA is computationally lighter, but you'll need a really small client or server (say 50 MHz embedded ARM processor) to notice the ...


27

There are a few reasons: traceabilty: Commands run with sudo are logged. Commands run with bash are sometimes logged, but with less detail and using a mechanism that is easy to block. privilege separation: almost every command is not the same as every command. There's still plenty which doesn't require root file editing: the web files are owned by a ...


26

In SSH, on the client side, the choice between RSA and DSA does not matter much, because both offer similar security for the same key size (use 2048 bits and you will be happy). Historically, version 1 of the SSH protocol supported only RSA keys. When version 2 was defined, RSA was still patented, so support of DSA was added, so that an opensource ...


25

When you connect first time to a given SSH server, you get the usual question with the key fingerprint; afterwards, the SSH client stores a copy of the server public key in the .ssh/known_hosts file. But the SSH client actually stores two keys: one for the server name, and one for the server IP. For instance, assume that server foo.example.com has IP ...


25

It is very common. Many botnets try to spread that way, so this is a wide scale mindless attack. Mitigation measures include: Use passwords with high entropy which are very unlikely to be brute-forced. Disable SSH login for root. Use an "unlikely" user name, which botnets will not use. Disable password-based authentication altogether. Run the SSH server on ...


23

Disable Root Login - Most automated attacks will concentrate on the root account so disallowing logins from that account is a good place to start. Only Allow Certain Groups/Users - Limit what users and groups can SSH to the system. Limit by IP or IP Range - One of the most effective ways of securing your system against SSH attacks. Use Key Based ...


21

This is not a "one is better than the other" issue. Both increase the burden of an attacker to break into your system: Using (and enforcing) keys increases the "quality of the password" ("mypassword123" vs "long_binary_asymetric_keypair_here"). Humans are very bad at remembering long passphrases with good entropy. Using 2Factor auth ensures that an ...


20

The chance is very much lower than any of these events: The computer spontaneously catches fire during the key generation process. Great Britain is wiped out by a falling asteroid during the very same second. A rogue gorilla escaped from a zoo enters your living room and mauls you. You win millions of dollars at the lottery three times in a row. So the ...


19

Based on a talk at the CCC conference - 28C3: How governments have tried to block Tor - the Tor Project has the best track record in this dynamic and challenging field, and it can be used for SSH. Innovative usage of Tor bridges is one of the latest developments. The 28C3 Tor talk is also on YouTube and the slides are at ...


19

What happens for private key storage is a bit intricate because it involves several layers of underspecified crud accumulated over years and kept for backward compatibility. Let's unravel the mystery. For its cryptographic operations, including private key storage (that which we are presently interested in), OpenSSH relies on the OpenSSL library. So OpenSSH ...


18

There are mostly two kinds of attackers: the automatic, and the targeted. Automatic attackers are not humans; they are infected machines, part of various botnets, which try to expand their basis by finding other machines to infect. Their strategy is mostly random: they try random IP address for an open SSH server, then try common passwords for common ...


17

The General Assumption of Security(*) is: The attacker is smarter than you, he has a bigger computer, he knows your own software better than you, and he is after you, specifically. So one has to assume that the keylogger will also monitor SSH session and slurp keys from thumb drives. Or, more appropriately, you cannot know how much secure you are if ...


17

A passphrase-encrypted key provides two-factor authentication, but only if used correctly. It is easy for the user to misuse the key, providing only a single factor, and the server cannot detect incorrect usage. Hence a passphrase-encrypted key cannot be considered two-factor without additional assumptions. From the point of view of the system as a whole, ...


16

I'm going to take a different position from others here. My recommendation: There's no need to change your SSH private key, unless you have a good reason to change it. Rationale: Crypto doesn't wear out. It doesn't become weaker with repeated use. The biggest reason to change your private key is if you have a reason to suspect it has been compromised or ...


16

The known_hosts file lets the client authenticate the server, to check that it isn't connecting to an impersonator. The authorized_keys file lets the server authenticate the user. Server authentication One of the first things that happens when the SSH connection is being established is that the server sends its public key to the client, and proves (thanks ...


15

I would think of an IP address as being "somewhere you are" rather than any of the traditional "something you know", "something you have" and "something you are" that are part of 3-factor authentication. Although IP addresses are trivial to spoof, TCP connections are not and SSH is a protocol built on top of TCP. The IP address of a TCP connection is a ...


14

It's as secure as your computer. The key is sitting, unencrypted, in RAM; an attacker with physical access to your machine, or remote root access, could obtain it. Think of it in the same terms as if your coworkers used a password safe program and left it up on the screen with the database available without password entry; if you lock your workstation when ...


14

Using valid SSL/TLS connection by making sure you're always connecting to the https:// version of the website and that the browser isn't giving you any warnings or errors, is your first line of defence. An addon called HTTPS Everywhere can be very helpful here. The approach you're proposing (SSH to your trusted network) is a very standard approach. I use it ...


13

Compared to a stored list of (long and random) passwords, a stored SSH private key offers the same security: things are safe as long as your private file remains private. The private key, however, is much more convenient, both practically (right now, the SSH clients support it out-of-the-box, contrary to a custom file of passwords which you must use with ...


12

Another important advantage of RSA over both DSA and ECDSA is that you don't ever need a secure random number generator to create signatures. To generate a signature, (EC)DSA needs a value that has to be random, secret/unpredictable and can never be used again. If one of those properties is violated, it's possible to trivially recover the private key from ...


12

Nothing. The attacker already has it: it is distributed with the OpenSSH source code. This file is used to define the group in which the Diffie-Hellman key exchange may run; the group description is public, it contains no secret value, and can be shared at will. OpenSSH includes several group definitions and selects one at random just because they are ...


12

If you have unfiltered https you can do something like AjaxTerm or any other AJAX or HTML5 based terminal emulator running on a protected site within a webserver that can either connect to a local ssh daemon or in certain cases to remote ones on other interfaces of your machine. Another option (tough a bit obscure) if you have ICMP to your box would be to ...


12

With SSH, things are done like this: on the laptop, run ssh -N -D 5000 proxy-machine (where proxy-machine is the DNS name of the "Web Proxy" machine); configure the browser to use the SOCKS protocol on localhost and port 5000. This is convenient, and activated in much less than 20 minutes. It has, however, the following consequences: The laptop user ...



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