Tag Info

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


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


4

In regards to your first question: The protocols you use will matter when leaving the VPN and going to the servers that you are trying to contact, so anyone sniffing traffic to those servers will be able to see what's being sent. In regards to your second question: If another person using EC2/Digital Ocean were able to sniff your traffic through that ...


3

As for the DNS: normally, the principle of the SOCKS protocol is that when a client wants to connect to server example.com on port 80, it sends through the tunnel the message "please open a connection to port 80 of example.com and forward the bytes back and forth", so the name example.com will be resolved on the other end of the tunnel (here, your home ...


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


2

You say "SSH is fast". It's not. It's fast enough for its intended purpose (remote shell access and occasional file transfer/sshfs) but it's definitely not fast enough for IPC, let alone efficient. On a local machine there's never any need for encryption between processes. If an attacker can read what you're sending to localhost, he can most definitely read ...


2

What if we sent the hash? If the hash were the authentication parameter, and not the password, then the hash would be the authentication parameter. To explain that tautology in more depth: a password is hashed so that if the data store of passwords is compromised, one doesn't have a functional authentication credential. For that reason, it is the password ...


2

An investigation should easily conclude that a computer on their network, assigned to you, is connecting to a consumer-grade ISP host on port 443 using SSH and not HTTPS (content inspection can easily determine what protocol you're using, including the ability to detect SSH traffic). The exact content of this traffic should be opaque (but even this is not ...


2

The connection between you and your proxy is encrypted. It goes through the corporate proxy, which can only see encrypted traffic. As you said, the proxy will register a connection to your proxy IP address and can eventually monitor the quantity of data going through that connection (it is a common way to detect proxy). It is possible that DNS requests ...


1

I suggest to avoid even installing sudo on your systems: it's an additional attack vector with usually no justification for having it. I wrote an article on the sudo (mis)usage if you are interested to learn more on the topic: http://dmitry.khlebnikov.net/2015/07/should-we-use-sudo-for-day-to-day.html Re: the original question - if you need some privileged ...


1

This can probably be done with the Snort Intrusion Prevention System, though Snort rules for SSH are generally used for things like brute force login detection and seeking SSH exploits. However, I think you'll find that being too draconian, especially on sysadmin-type employees, will likely trigger attrition. Set a corporate policy if you must, but don't ...


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


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



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