Hot answers tagged

35

I'm completely confused, though. What is the security benefit here? Nothing. The most likely scenario is that something in between is timing out the connection after 5 minutes to conserve resources. That could be a firewall, a WAN accelerator, an SSL accelerator, etc. Or it could be just a bad default setting. Who knows? Network admins often have ...


28

From the security they provide in theory FTPS and SFTP are similar. In practice you have the following advantages and disadvantages: With FTPS client applications often fail to validate the certificates properly, which effectively means man in the middle is possible. With SFTP instead users simply skip information about the host key and accept anything, so ...


24

The sysadmin raises a valid point. (but his interpersonal skills might need work) SSH is a complex protocol, and openssh implements a lot of functionality. All this functionality offers attack vectors, and it is very hard to be sure that none of these vectors are exploitable. Even if openssh is without bugs (which it isn't), knowing about all the right ...


19

This sounds like a good example of a security "cargo cult". A security control has been implemented blindly without understanding the context involved or indeed implementing it correctly. Generally speaking in security the point of an idle timeout it to reduce the risk of situations where a client machine is left unattended and a malicious user gets to the ...


8

I'm completely confused, though. What is the security benefit here? It might not be a question of security but have a different reason. Unfortunately your question only offers your view so we can only speculate what the real reason might be. One explanation might be that there is a simple stateful packet filter where the states time out after 120 ...


6

Both protocols have advantages and disadvantages, as explained very well in this comparison article. This said, since the question is specifically regarding security, there are a few considerations that should be taken into account when choosing which protocol is best in certain specific conditions. FTPS and FTPES use SSL or TLS to encrypt the control/data ...


5

Absolutely; they can see every packet going across their network, and analyse and block it as required. They should draw up a detailed acceptable use policy if they're going to make you use your own machine for work. Check if there is one. If they haven't told you not to tunnel personal traffic back home then they can't really complain if you do it!


5

When you authenticate to Github with your SSH key, that authentication doesn't become part of the repository in any meaningful or lasting way. It causes Github to give you access for the moment, but it doesn't prove anything to anyone who is not Github. When you GPG-sign a git tag, that tag is part of the repository, and can be pushed to other copies of ...


4

The problem with this approach is that the same identity is used by every destination, so sites can swap notes to see where you've been and draw correlations that you may not want to expose. There are several ways to solve this issue, such as the one used in the FIDO U2F security key. In this case, the device contains a symmetric key (not an asymmetric key ...


3

Depending on how the files have been deleted (and your file system) there might be forensic tools that evaluate the journal and retrieve as much information still alive behind the scenes of the filesystem. For example, if you are using ext3 or 4, extundelete may help when the attackers were sloppy with deletion and didn't overwrite the files. There are ...


3

I suspect your key are affected by the issue of weak keys, that was generated using the process ID as seed: https://github.com/g0tmi1k/debian-ssh Note that this are only dependent on which machine you generated your keys on, NOT the SSH'ed machine. There is then a possibility that the attacker predicted your key. Thats why I suggest regenerating the keys, ...


2

Using the same private key across separate domains is basically secure. If you authenticate to a system, you don't give away you private key, and that system cannot impersonate you. So you can use your key across work and personal systems, and a work system cannot then access your personal systems. However, there are often reasons to use different keys. For ...


2

I don't think, there was any vulnerability in this, at least not in openssh. The code resulting in this error was added in this commit and it is referencing recommendation from ietf-drafts. Probably RFC4252, which states today: The 'user name' and 'service name' are repeated in every new authentication attempt, and MAY change. The server ...


2

The weird thing is that I get a different key when accessing the Pi over the internet instead of via LAN: Manual page for sshd describes format of your known_hosts file: SSH_KNOWN_HOSTS FILE FORMAT Each line in these files contains the following fields: markers (optional), hostnames, [...]. The fields are separated by spaces. Se we got to ...


1

Using ssh instead of https will probably cause some maintenance headaches. There could be a firewall between your devices and the server (say at the APN exit or at your company's entrance) that will block ssh access. Even if there isn't, allowing ssh access to the server means, well, allowing ssh access to the server with all the risk that opening up shell ...


1

It is in the source code of openssh as described in the RFC and we can simply trace its source from there: /* K1 = HASH(K || H || "A" || session_id) */ if ((hashctx = ssh_digest_start(kex->hash_alg)) == NULL || ssh_digest_update_buffer(hashctx, shared_secret) != 0 || ssh_digest_update(hashctx, hash, hashlen) != 0 || ssh_digest_update(hashctx, ...


1

The "normal" way to use remote X11 is to have the X11 server run not on your server, but on the machine which is physically in front of the user. Then use ssh to do X11 forwarding, so that the application on your server talks to the X11 server that runs on the client machine. (Yes, the terminology is a bit confusing. "Your server" is the machine you are ...


1

Use this command: ssh-keygen -p -f keyfile


1

The left hand side of the output of ssh-keygen -H -F 192.168.1.92 is the hash of the IP address. If you were to run the command without the -H option you'd get something similar to: christoph@christoph-laptop-14-04:~$ ssh-keygen -F 192.168.1.92 # Host 192.168.1.92 found: line 9 type ECDSA 192.168.1.92 ecdsa-sha2-nistp256 ...



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