Tag Info

New answers tagged

1

The good old safe-with-two-locks analogy: Alice has a safe with a message for Bob. (The message is what you refer to as the 'guidelines' for the encryption of that tunnel). She locks the safe with the message in it with her lock (and keeps the key). Bob receives the safe, but cannot open it. Instead, he adds his lock on the safe, and send the ...


11

Though the question is about SSH, the same concept as in SSL apply, so see this answer which explains it all. Short summary: it's magic. Asymmetric cryptography magic, to be precise.


3

In SSH, you have two sets of key pairs: one for the server and one for the users. The server key pair is mandatory but it is typically generated during the installation of the server: all you have to do is validate the server public key fingerprint (a simple hash) and, as long as the key is unchanged, your client will silently connect. The key pair you use ...


7

Short answer: there is necessarily a public/private key pair on the server. There may be a public/private key pair on the client, but the server may elect to authenticate clients with passwords instead, SSH is a generic tunnel mechanism, in which some "application data" is transferred. One such application is the "remote shell" which is used to obtain an ...


4

It's able to function because the keypair already exists on the server. The SSH server has the keys necessary to protect the information in transit. SSH server will use a public key, that client device uses the public key to encrypt information sent to the server. The server then uses its private key to decrypt that information and process. See ...


3

No, it is not at least with OpenSSH -- there are no options to operate in this mode. It is for authenticating with remote servers (validating identity) and then encrypting the network traffic between ssh client application and the remote sshd server. You could try compiling a library from OpenSSH that uses its encryption modes and create an executable ...


0

History has shown that Theo de Raadt is somewhat of an asshole. I wouldn't read too much into what he has to say. If you're concerned, check the version of OpenSSH on FreeBSD and the OpenSSH on OpenBSD, diff the two, and analyze the differences.


7

One usually evoked solution is Fail2Ban: this is a system which uses the firewall rules (iptables) to block incoming connections from IP addresses from which some kind of exhaustive search attack is apparently in progress. This, of course, won't work with a distributed DoS, coming from thousands of distinct IP addresses. In general, very few things resist a ...


1

You can start by blocking all the outgoing ssh traffic form your server using iptables : #iptables -A OUTPUT -p tcp –dport 22 -j DROP


4

It cannot be repeated enough :-) No But! If you run any other services on the host machine, OpenVPN for instance, wich uses OpenSSL, its vulnerable and can be exploited.


3

When you log in with SSH, your client has the private key, and the server has the public key. Therefore, no vulnerability on the server can leak your private key, since the server doesn't have it. The server cannot use Heartbleed to get the private key from your client, since that's an SSH implementation, and only OpenSSL SSL/TLS connections on version ...


8

No. OpenSSH uses a very limited subset of the OpenSSL library, and that subset does not include the code involved in the Heartbleed vulnerability (or any of the other SSL/TLS code, for that matter). Additionally, the Heartbleed vulnerability doesn't permit an application to read memory outside of its address space, so, for example, a vulnerable web server ...


2

My guess is you (or someone else on your server) is doing SSH proxy tunneling and connecting to stackexchange or another site using gravitar, and for some reason those connections to gravatar were timing out. I do not think my home server is hacked and I see similar messages in my auth.log, but only on days when I was using the SSH proxy. The messages are ...


3

Due to the use of the Diffie-Hellman key exchange, knowing the server's private key does not help a passive-only attacker. If the attacker wants to learn the data, then he must go active. If the attacker knows the server private key, then he can impersonate the server, i.e. run a fake server and let users connect to it. For a full Man-in-the-Middle attack, ...


1

If the client initially starts a connection with the correct server, then no, the attacker can't do anything against that connection, but if the attacker can get the user to attach to them instead, then they can play the middle man and make a connection with the client and a separate connection with the server as long as client certificates are not being ...


0

My guess would be that the worst an attacker could perform is impersonating the server, leading users to log into his system instead of the legit one. This actually means that attacker can read traffic, acting as proxy. Question is: will key-based authentication have some positive effect for client Answers of that question covering that in some ...


1

Yes, with AppArmor it might be possible: I have tried arround somewhat with using MAC (mandatory access control) and the AppArmor LSM (linux security module) and I found, that you might have a change using AppArmor to make /etc/ssh/sshd_config impossible to be written to using sudo. This AppArmor profile would limit what the user can do after having ...


3

In addition to RSA (the cryptosystems invented by Rivest, Shamir, and Adleman) not being equivalent to RSA Data Security (the company also founded by them 5 years after RSA was invented), the original creators of the cryptosystem sold their company to Security Dynamics in 1996. By that time, Shamir and Adleman had already left the company, and Rivest had his ...


9

You are confusing RSA, a family of cryptosystems that relies on the difficulty of factoring products of large prime numbers, with RSA Security LLC, a company which sells security-related products. RSA and RSA are both called RSA after Messrs R, S and A, who both invented the RSA cryptosystem and founded the RSA company. The company was founded in part to ...


1

I think you're confusing RSA-the-algorithm with RSA-the-company. The company was found to be complicit with the NSA in promoting a compromised pseudorandom number generator. This had nothing to do with the RSA public key encryption algorithm used in SSL/TLS.


0

Yes, there are many reason why you would want to have a complete audit trail of everything done on a given server (or everything you do on any server), and auditing is just a small fraction of it. Often information that later proves critical is only ever dumped to the console (not to any log file), and having a history to go look through can be very ...


1

File /etc/ssh/ssh_config is a global configuration for SSH clients. /etc/ssh/sshd_config is for configuring the SSH server. Make sure you modify the right one. When you specify "AllowUsers", SSH automatically denies access from all unlisted users. There is no need for a PAM file. If you have read the man page, you'd know about this. "man sshd_config". ...



Top 50 recent answers are included