Tag Info

New answers tagged

12

No. It has nothing to do with the key generation. One can encrypt a key, later remove the password, change the password, and/or change the algorithm. The reverse is also true one can start with an unencrypted key and later encrypt it. The encryption is done client side after the keypair generation is complete. It really is no different than encrypting ...


3

Microsoft is hoping to incorporate SSH: http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx However, that has been attempted before and then fell by the wayside. As for your question, there is no standard or overriding reason why a user might enable SSH but disable SFTP, but there can always ...


0

SFTP and other SSH solutions are not standard on Windows mainly because they are not standardized and properly documented in RFCs. Microsoft provides the bare minimum if any facilities to enable SSH. That said I had no issues using it with ported Penix utilities compiled with Cygwin. Just don't expect it to make it's way into official development framework ...


8

Because SFTP runs over the same protocol as SSH, there is no valid technical reason to refuse to enable SFTP. That said, there may be company policies that prevent this. There is a big difference between an SSH connection to issue commands, and an SFTP to transfer files. A company might accept the risk of allowing an approved account to access another ...


1

The answer is yes, it is possible. However, there are some significant limitations. Through the use of IP spoofing, it could be possible to establish a connection which could be used to deliver a payload to the target, but it will not be possible to establish a true bi-directional TCP connection. In simple terms, the attacker can get the target machine to ...


0

The presence of any service on the Internet will lead to it being attacked to a certain degree, as some attackers are just looking for free resources (bandwidth, CPU power) and don't really care too much about what's on the host. Assuming that you patch the OS it's not too likely that the SSH service was compromised directly, but if you're running a web ...


0

Newer versions of OpenSSL (>= 1.0.1 at least) use PKCS#8 format for keys. So, if you extract publick key from certificate using command openssl x509 -in certificate.pem -noout -pubkey >pubkey.pem You need to use following command to convert it to authorized_keys entry ssh-keygen -i -m PKCS8 -f pubkey.pem -out option of the req command of OpenSSL ...


1

It is not currently possible to bruteforce an SSH connection using only keys-based authentication. A VPN on top of an SSH connection does not therefore add substantial security. It would be better to concentrate on reducing the collateral effects of bruteforce attacks on your SSH connection (DoS and logs trashing would be the top ones), which is described ...


1

SSH and VPN provides basically the same encryption mechanisms. Let’s imagine they both provide the same security, and you configured them well. If an attacker is able to decrypt your VPN communication in a reasonable time, it probably means that he can do the same thing for SSH in roughly the same time. So, you did doubled your defence, but at a relatively ...


6

Before the attacker can send any data to the SSH server, he has to complete a TCP handshake. This means the attacker has to guess a 32 bit sequence number. (If SYN cookies are used, the attacker's chances may improve.) Assuming your server is generating good sequence numbers, this will significantly reduce an attackers ability to attack your SSH server ...


5

In short no. Because SSH runs on TCP (although there is a UDP version, this is unusual) a TCP handshake is required to commence the SSH protocol's own authentication and its following communication. A private address will not cross your perimeter router to and from the public internet so any spoofing of an internal address as it comes inbound (assuming no ...


3

Yes, as deviantfan has explained, if you do it that way, Bob can see your traffic. A more secure way to achieve your goal is to use the proxy features built into SSH. Add the following to your ~/.ssh/config: Host C ProxyCommand ssh -W %h:%p usera@Bob Note that the -W option was added in OpenSSH 5.4; if you don't have this, you can use netcat instead ...


3

Yes, Bob can see the communication if he wants. Essentially, the second ssh call is executed in a shell on Bob´s computer, similar to someone sitting there and typing on the real keyboard. Bob´s computer must have it (and every input) unencrypted. And the output from the target comes back to Bob, gets "displayed" in the shell of usera, and because of that ...


0

Try this: ssh cody@localhost This works for me, so it should work for you with an ssh-server installed, unless you have blocked the port. But for what purpose - on the same device? I doubt if it would make things more secure.


0

Thanks for all support. These have been my findings after a thorough investigation: The ownership for both scripts found in /tmp has been the Apache user. The /tmp directory is writable by Apache. I compared the creation date with any relevant log and I found in the Apache logs how they entered in the system. It turns out that they exploited the magento ...


0

No, because /dev/random gathers environmental noise from device drivers. So unless you happen to have exactly the same events happening at the exact same time in both VMs, their random pool will differ enough to make this kind of attack impossible (or at least infeasible).


2

The course of action is to wipe the machine and install everything from the stored image or from scratch. It's just too hard to be confident that you've cleaned them. Especially once the attacker has gotten root access.


0

For me, it contains the same string. the server has: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBLmw2JjbKMO5LXTcJ67et6TBZeLff1WghM6koKjiHGh+gBbZzHrhDj20MuTxTB1kaTYh7f9T2G/zmhVpFMyUUoQ= and the client has |1|some_base64|more_base64 ecdsa-sha2-nistp256 ...


0

I think there is one aspect of this comparison that was overlooked. user185 came close but didn't quite get there. I agree that these are apples and oranges and feel a better apples to apples comparison to be HTTPS and SSH. HTTPS and SSH utilize different layers of the OSI model and therefore encrypt the data at different times in the transmission. Then ...



Top 50 recent answers are included