New answers tagged

2

Most vendors using SSL/TLS commonly use OpenSSL who keeps a detailed record of vulnerabilities associated with SSL/TLS. Subscribing to security sites like Bugtraq will keep you in the loop regarding disclosed (known) vulnerabilites associated with OpenSSL and may tell you about the other SSL libraries as well. You would also want to subscribe to other ...


0

MD5 works perfectly fine for ensuring a file hasn't been altered. Where it (and SHA) is "bad bad bad" is for hashing passwords. The reason? MD5 and SHA are designed to be fast, which makes them easy to brute force with a GPU. For passwords, use a slow hashing algorithm like bcrypt with a random per user salt. In my use case, I am granting access to ...


4

No, you should not be worried, but you should be checking GitHub's server fingerprint rather then relying on IP addresses. With git command you do it only on first (ever) connection. If the public key (corresponding to the fingerprint) is in known_hosts file, subsequent connections to github.com cause only warning if the domain got resolved to a new IP ...


0

I can't make comments yet, as most of security-related answers are on reverse-engineering stackexhange . com. It sounds as though someone is trying to bruteforce your ssh server (happened a lot last year from TK, RU and CN to my amazon EC2 instance). Like munkeyoto stated, if the attacker's MTU is set too high it can cause runts, which means the packet size ...


0

While I am not completely sure an admin could not exploit it. You can at least limit the risk by using proper crypto hardware. (e.a. a smart card (in usb form) ). To store your key on. that way you at least know when someone is asking for your key information. Additionally you limit the time available for anyone to do such an attack. And you have to do ...


1

I am working remotely on a school server via SSH from home. I would like to access a private GitHub repository from the remote system with SSH. You can use ssh-agent forwarding to solve this, without storing any key material on the server. This is preferred way and what is this for (preferably adding a keys to the agent with confirmation for every action: -...


2

Considering your explanation: I'm not worried about them seeing the contents of my GitHub repository - I'm concerned about them being about to use the private key to impersonate me and wipe our repo or clone other private repositories that aren't already copied onto the server. You may consider using GitHub feature called read-only deploy key. In a ...


0

Whatever way you approach such a question, if there is someone with greater administrative rights than you, there can be absolutely no way for you to ensure complete security and privacy of your data. They can look at your files, copy them, and implement tons of ways to spy on everything you do. If you feel your GitHub account justifies greater security, ...


2

Why use dedicated SSH keys for different hosts (like GitHub)? Answer: Revocation. When you lose an SSH key, you have to revoke it on everything it had access to. If you use the same key on GitHub as you use to SSH in to your personal web hosting, you have to remove the key from both places. One key per service means none of your other keys are impacted by ...


0

The GitHub advice is possibly over stating the risk. Using the same ssh key on multiple systems has nothing like the risks associated with having the same password on multiple systems. However, there are some other factors to consider which may result in someone having more than one ssh key. The most obvious reason to have more than one ssh key relates to ...


0

This has been extensively explained but here is the summary: This problem happens when either party decrypts the first cipher block of the SSH packet and checks the packet length. Obviously, the packet length must be at least 5 bytes. RFC 4253 specifies that any implementation must support the length of the whole packet to be at least 35000 bytes....


1

SSH public key authentication does not support anything like key revocation. The list of "allowed" keys is store in the ~/.ssh/authorized_keys and if you remove the key from there, you revoke the access (if this is what you want to hear). Revocation list is related to Public Key Infrastructure usually based on the X.509 certificates with certificate ...


0

Two things. 1. It's the way it has always been Biometrics or hardware tokens (such as RSA SecurID) were the standard for 2FA, and then everyone got cell phones and later smart phones. Suddenly it was easy to create a second factor by sending people an email to their smartphones, or to an app on their smartphones, or an sms to older phones. That you could ...


1

For the general public, any 2-factor authentication should be understood in under 2 minutes, otherwise it will fail very quickly since few people will be able understand it. That generally requires using something people are already familiar with, or is very simple. PGP, and SSH are complex technologies that very few people, except developers and IT ...


0

The EnigForm FireFox plugin was a very promisong approach. And in combination with an OpenPGP SmartCard it was at least as secure as FIDO U2FA. It's a pitty it didn't gain widespread adoption.


1

So in building the private key for rsa it will use ssh_host_rsa_key, username, MAC Address, and /dev/random as a seed for my local private key for the user." No. It is not true. The private key is generated only based some bytes from /dev/random, which are formed into the private key inside OpenSSL. Host keys are not used, because normal user who ...


4

Because additional auth factors should, ideally, be out of band. Like a phone, or token, or some kind of telepathic message. U2F is good because you CAN'T extract the private key and it requires a physical touch to the device before it will sign.


3

SSH actually requires you to configure different keys for different users. Each user account on the destination machine has its own ~/.ssh/authorized_keys (doesn't necessarily have to have, it might not exist). Let's assume you have server and client. server has users set up as follows: /home/srv_user01 /.ssh/authorized_keys ...


10

Lack of portability SSH and PGP are widely used, but they are not web technologies. There has been an equivalent web technology for many years - SSL client certificates. However, this is not much used. The reason is the lack of portability. If you have an SSL client certificate on your home desktop, it's difficult to move it somewhere else. So you can't ...


25

Let's check out what PGP and SSH actually offer for this purpose: PGP: Client must install PGP software which is not installed by default in the majority of the systems. Client must create a PGP key pair. Then he must send the public key to the server so that the server can use it later for validation. When authenticating with 2FA the server will send a ...


5

Running ssh -vvv host, at some point, you will see something like: debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password The first two lines describe what methods are offered by the server and the ...


1

Let me provide a high level picture. Clearly, you understand the need for secure communications, be it SSH or HTTPS. Secure communications mean that the channel is encrypted. Generally speaking all encryption algorithms fall into one of two categories: Symmetric encryption. One key. Same key is used to encrypt and decrypt. Fast. E.g. AES. Asymmetric ...


2

Basically, what makes it better then a really long password? They are not transfered over to the server (as even the very long password have to be transferred). It is not insecure in the ssh case (the channel is encrypted unless you use broken ciphers), but in theory it can be intercepted by Man In the middle or malicious (super)user on the remote server. ...


1

I'm not sure what you're comparing SSH with the "very long password". SSH provides a secure means to send your user login and password to a remote server. Or you can use a client's public key. Asymmetric keys are generally harder to break because they're not subject to users creating bad passwords. Public Key Based Authentication is preferred for that ...


1

Adding a little to His Majestic Ursinity, it could be and I'd bet is (was) an SSL2-format ClientHello offering upgrade to TLS1.0. In 2013, before POODLE and then DROWN motivated people at last to eliminate outdated SSL3 and even SSL2 interfaces, it was fairly common for TLS clients to use SSL2-format because they had been configured or coded that way years ...


2

For the purpose of authenticating a server to a connecting user, the difference in the implementation which you observed is not really a technical one. Particularly: SSL does not require the use of a trusted third partyーyou can use SSL with self-signed certificates (which would be equivalent of how SSH keys authentication works). SSH can use a server ...


14

Because they're used differently. TLS/SSL x509 certificates as commonly used in HTTPS is used to connect to public systems, i.e. systems that are accessed by a large number of people, most of whom had no prior out-of-band connection with the owner of the system. SSH, on the other hand, are primarily used to access private systems by a small number of server ...


3

A malicious user cannot exploit a publicly known fingerprint of a public key, because verification is not limited to comparing the fingerprint to a fixed value. Server presents two pieces of information to a client: a public key a message encrypted with its private key (which exists only on the legitimate server) On the client side the message is ...


2

SFTP is subsystem of SSH. When you run sftp command, it internally creates ssh connection for you and run sftp-server on the other side. SSH (Secure SHell) itself is separately for remote shell. SFTP (SSH File Transfer Protocol) itself separately is for file transfer, as you can make up from the shortcuts.


2

You can use ssh-agent to add a smart card and then forward agent to the other host. This will let you authenticate on the second host from the first using your local smartcard. In short: eval `ssh-agent` # if the agent is not running yet ssh-add -s /path/to/pkcs11.so # probably /usr/lib64/opensc-pkcs11.so # or Ubuntu: /usr/...


3

There would never be a valid reason to use SSH for communication between processes running on the same device, unless that device was used to simulate a network, in which case it would act as multiple virtual devices anyway so technically not be the same device. Use unix domain sockets instead. Note that domain sockets are not the same as the Secure Sockets ...


1

We ship it and use it in Fedora and RHEL. It is here for a long time and it is using the code from openssh for almost all the public key operations (and openssh is using openssl). The code is quite fair. The pam_ssh_agent_auth itself basically does only verification that the public key matches and that the signature provided by ssh-agent is valid. All the ...


89

You could write some Python code to upload an SSH server binary and then run it, this will give you full SSH access under the privileges of the Apache user. From there you can easily read the Python app's config files and connect to the database using the credentials from there, which will allow you to grab confidential data (no exploits needed here as the ...


0

No need to worry, these are just typical attempts to find vulnerable servers. You've Fail2Ban already installed, this way you decrease the brute force attempts.


1

DoS is just may request at the same time. Proof of concept is to run many requests to authenticate to one server in some time period. I don't know what more do you want to hear. Current OpenSSH version mitigates this with random early drop if the amount of the connections exceeds some limit and starts rejecting all the connection if the hard limit of ...


2

I'd recommend looking for non-recent versions of OpenSSH in your search. Since it's a relatively well maintained library, if there's any known exploits, they've likely already been patched. However if you look through the CVE list for working DOS methods on older OpenSSH versions, you'll be able to access all those nasty bugs that have already been patched! ...



Top 50 recent answers are included