New answers tagged

0

No, for the following reason: root could patch sshd to always try root's authorized_keys file as well as its own. Of course if root's private key gets stolen you have a bad day. Don't allow that. You would be much happier if root's private key only exists in /root on the server. If someone can become root they can steal it but that's of no account because ...


1

You have almost always timeout on inactive TCP session implemented in routers, switches and all that low level network machinery. It has little to do with security in the sense of protection against a deliberate attack, but just try to not exhaust resources because of buggy software failing to close connection, or other hardware errors in external network ...


3

As you may have noticed this has nothing to do with security whatsoever. Instead, the practice of killing long-lived dormant TCP connections has to do with bugs - it's a work-around for buggy software. One of the more famous examples of software leaving TCP sessions hanging is Internet Explorer (at least up to version 7). IE had the habit of not ending TCP ...


0

The answer is kinda blunt either which way you go in your rhetoric. Server side means are controlled by the person giving the file and theoretically safer if one knows all security features. A user side method would be the same but for the user. In these days we do not question the relationship of the two. Each must insure themselves of their abilities ...


12

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


34

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


39

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


45

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


12

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


26

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


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


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


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


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


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


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


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


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


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!


1

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


0

For example SELinux is probably better answer for your question (you can do that even with users, but it is probably too complicated). When using SELinux, your private keys are labelled with ssh_home_t (ex. from Fedora) and other applications running in different contexts are not able to access these files, unless explicitly allowed in policy. But ssh ...


0

I don't see the point in this measure. When you have an untrusted application you should rather run it under a special unprivileged user. Otherwise it would be able to detect how you accessed the files when you need them at some point.


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

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



Top 50 recent answers are included