Tag Info

New answers tagged

7

If you are Windows OS, there is a way to use torify your SSH using Putty client. Here are the configurations you need to set: If you are using a Linux distribution, it depends on which one you are using. For example, if you are runnin Ubuntu you can (How to use SSH with Tor?): Add the following block to the top of your ~/.ssh/config file. Host * ...


4

If such computation is a concern for you (for instance if you have a lot of successive connections), depending on your usage you may be interested in SSH ControlMaster Session feature. It allows SSH to multiplex several sessions inside one TCP connection, so the handshake is realised only once then each new session can just reuse the already established ...


2

The computation is not that heavy regarding the security advantages because if the server is spoofed or compromised, the attacker can not get the private key (and pwd); at best he can the signature which can not be very interesting for him because a signature cannot be re-used: that is why it is a worth while to perform some calculations for the sake of ...


0

Why not look into stunnel? This will allow you to tunnel a protocol over HTTPS. You will need a public endpoint on your Linux box at home to listen on port 443 and then you can connect to what you need through that.


0

There is one big hole in this, which is that it is difficult to prove who did what action with shared accounts. Not impossible, just more difficult. In addition, the shared private key is a bad idea from a defense in depth strategy. You can solve both problems by managing the accounts individually, which creates greater management overhead, but it shouldn't ...


0

The short The MITM needs the private key of the server to pose as the server and decrypt private messages you send to to the server. The public key of the server is for authenticating messages signed by the server and sending private messages to the server, so you still need to verify its fingerprint. It's okay if the MITM has the public key too. All that ...


0

"What is the justification for the ciphers being shorter than the key?" As I understand it, the asymmetric keys need to have a mathematical relationship to each other (Private and Public) which severely limits the number of possibilities you can have, whereas the symmetric ciphers have a much larger 'per bit' supply of combinations. This site does a ...


0

In addition to permissions on the files within ~/.ssh, depending on the platform, you could monitor any access of the files within the directory using auditd. This would allow you to see who/what is accessing those files at any time and alert you to any unknown/unsavory activity.


0

Given that any application running as the logged in user will have read access to that user's ~/.ssh folder, it seems trivial for the application to copy that user's private key and send it over the network. Yes, that is correct. A few safeguards to prevent ex-filtration of your private key are: Role accounts: Run any untrusted program using a role ...


4

As Naftuli Tzvi Kay stated a well worn solution is using a hardware device to manage your keys. Some alternatives for a software solution include: Making your private keys only readable by root / sudo Encrypting your private key with a password, so at least it will be non trivial for the attacker to crack it if they do steal Storing them in an encrypted ...


0

A typical best-practices answer would be to use something like LDAP. With it, you can define users, groups, and more. By connecting your SSH authentication backend via PAM to your LDAP server, you can maintain separate accounts for each member of your team. I may be mistaken, but you should also be able to maintain separate $HOME/.ssh/authorized_keys files ...


0

Store your private keys on a hardware security device.


0

Just don't keep your private keys world readable. Not everything in ~/.ssh is private keys. authorized_keys and stuff is fine to read. Also, you may benefit from doing some sort of network monitoring (maybe even deep packet inspection, though that's probably not that efficient) and/or auditing regarding user sessions so at least you can detect if they send ...


0

There are several technologies involved in creating a secure connection (the network protocol stack). Each layer solves its own part of the job to make connections work. The parts of the stack that are relevant to your questions are: HTTPS TCP IP You can notice that HTTPS sits on top of TCP, which works on top of IP. HTTPS cannot change how underlying ...


2

Both SSH and HTTPS (relying on SSL or TLS) use encryption, but are based on an established TCP/IP existing connection. This means that even if the content is opaque, all TCP/IP information are in clear and available to someone sniffing your network. TCP/IP information includes IP address of each peer, port numbers used. This gives a good hint about protocol ...


0

It depends entirely on the topology of the network used to connect your computer to the server. If your computer is connected to the server directly using an ethernet cable or similar connection, and those computers and cable are inside a secure room and you have made sure that nobody saw you entering the room then NO, nobody can know you have connected ...


6

Yes. This is called "Traffic Analysis". Broadly speaking, the useful information that can be obtained is who you're talking to, and when. So if you're ssh'ed into a server and the packets look like someone typing, it then looks like you're up and actively engaged in some activity with that server. The volume of the data going back and forth can be ...


2

Sure, they can. A proper encryption is supposed only to hide the content, but is not expected to hide: parties involved in the communication size of data exchanged timing of packets (anything else) Moreover, some data may be leaked from the initial handshake. For example, HTTPS with SNI leaks the domain you are connecting to in plaintext even if the ...


7

They can. In order to establish a secure HTTPS connection a handshake must happen between you, (the client, i.e. your browser or any other application) and the server. Any data sent within the handshake is not encrypted. About the risks, it's a broad topic to discuss. The plain information that you are connecting to some public server (Facebook, Gmail, ...


3

First of all, the answer depends on your SSH client. Let's assume you are using latest OpenSSH client. The SSH2 protocol starts like this: Client -> Server: Initiate connection, send client software version + SSH version Server -> Client: Server software version and SSH version Client -> Server: Client supported algorhitms Server -> Client: ...


2

Alternatively, you might consider the JuiceSSH client. It stores your keys in its private app directory. In addition, it encrypts its storage so even jailbroken phones offer some level of protection. Sources: - @JuiceSSH: "External storage won't work as keys are imported into the internal JuiceSSH database". - @JuiceSSH: "They [ssh keys] are stored in an ...


1

It's best to generate a public and private key-pair for each host, and copy all public keys to one server. When using public key cryptography the goal is to keep the private key secret. Option number 2 would mean that all hosts could impersonate the other hosts. While this might not seem like a bad idea for data transfers, SSH keys are also used for ...


2

Using unique keys would be better from a security standpoint. Create a unique key for each server and distribute it using the copy-ssh-id command. Related: http://askubuntu.com/questions/4830/easiest-way-to-copy-ssh-keys-to-another-machine


3

No, this is correct, you are putting PPP packets into your SSH connection. The idea of a VPN is that you are tunnelling, which basically means that you have an SSH connection (a tunnel) that looks like PPP when you are sending something into it. Thus, if you send a request through your tunnel with a protocol like HTTPS, your packet on the wire will look ...



Top 50 recent answers are included