Hot answers tagged

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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


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


1

Somebody brute forcing my SSH key is not an issue in my mind, somebody with resources like that (if it is even possible) can easily break into your office. Listening on a non standard SSH port is something that many people recommend, and it can't hurt. (Probably does not help either.) The only issue I worry about with a public ssh port is that if there is ...


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



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