New answers tagged ssh
Taken from research!rsc: "Last week, Debian announced that in September 2006 they accidentally broke the OpenSSL pseudo-random number generator while trying to silence a Valgrind warning. One effect this had is that the ssh-keygen program installed on recent Debian systems (and Debian-derived systems like Ubuntu) could only generate 32,767 different ...
I don't have enough rep to comment, so I'm answering. Now as I understand this a game, certain liberties might have been take. I could be wrong is it possible that the game did the following: Installed the public key in authorized_keys The private key isn't encrypted, not requiring a password Restricted access by IP, so only local clients could ...
If it's not needed, it should be closed. Vulnerabilities You can never be sure if there are no vulnerabilities in MySQL itself. Here is an example for a DOS attack (and it's not the only possible attack). Allowing non-ip restricted remote access to MySQL Allowing remote access to MySQL is not a vulnerability by itself, but there are scenarios where it ...
Just opening the port isn't intrinsically any more dangerous that opening a SSH port. The problem is that any application program that could USE the port could be hacked, and then be used to compromise your database. Anything running on the client side is inherently not to be trusted.
Assuming you do have the resources to do it (perhaps you intentionally make it small enough to be feasable and thus insecure..), what format is it in?
John the Ripper supports cracking SSH private key passphrases. If you provide a dictionary it will be even faster. Alternatively, you can also use Phrasendrescher.
See a similar question on Unix & Linux Stack Exchange for background. You aren't running into any kind of security restriction. This is not related to the use of BusyBox, it's related to the filesystem used by the router. With filesystems for which a driver supports writing, mount -o remount,rw / would remount the filesystem read-write. You need shell ...
It might be that you're interacting with read-only memory, but an ordinary file system can be remounted to write. When you're a root just do: mount -o remount,rw / And it should remount the filesystem to be writeable. Anyway, if you want your router to do more, replace the firmware with a better one.
Obviously, if an attacker manages to get any foothold on the network, they'll be able to move laterally just as easily as you can. But if you understand that and want to accept the risks: Configure SSH to use PAM (UsePAM yes in /etc/ssh/sshd_config), then put the following in /etc/pam.d/sshd: auth sufficient pam_permit.so This will immediately grant ...
Assuming OpenSSH, you can (still, but not by default) use HostbasedAuthentication which is the same (fragile) scheme used by classic rsh/rhost before ssh was invented. Namely, if the client IPaddress maps to a hostname listed in a server system or user config file, the connection is accepted. This relies on correct and available rDNS for your local/trusted ...
If they want the connection to go through all the way to the legitimate server: absolutely nothing. (Well, nothing a passive observer can't learn.) The endpoints establish a shared secret via DH, which is part of the data signed with the public key. (Source.) Consequently, if the attacker subverts (MITMs) the DH key agreement, the authentication will ...
You should start off by reading carefully the Wikipedia article on asymmetric encryption. Public and private keys work together: A third-party can encrypt data with your public key, and you will be able to use your private key to decrypt it. Nobody else will. You can use your private key to encrypt data and anyone who has your public key will be able to ...
There are two risks that immediately occur to me that would be reduced by using a VPN You're avoiding the risk that a single vulnerability provides access to your systems. With straight SSH/RDP a remote code execution vulnerability in the service could allow complete compromise of your environment. With a VPN which then allows access to the service, the ...
A possibility would be to use 'sudo' (or a script / alias relying on it). Thanks to sudo, you can allow your users to temporarily use another (not necessarily root) in order to execute a very specific command: Create a new account which will own the private key, Configure sudo so your users can launch an SSH client using this account and its private key. ...
1024 is considered the minimum key size for RSA at the current time. For general purposes i would say that 2048 is enough. However, if you will use this key to transfer highly sensible data (e.g. related to bank accounts or important server passwords etc..) I´d go with 4096 bits.
Depending on how paranoid you are and how secure the server needs to be, 2048 should be enough. It's going to take many years for someone to break that.
Top 50 recent answers are included