rrsync is designed to be used as a forced command for a particular key, so it should be exactly what you want.
A forced command is set up using the command option for a key in an authorized keys file and is then always run whenever this key is used for authentication, no matter what command the client requested. But it has access to the requested command so it can for example implement a validated, restricted version of it and that's what rrsync does.
You use it like this:
command="/path/to/rrsync -wo /allowed/directory/",restrict,from="a.b.c.d" ecdsa-sha2-nistp521 AAAAE...
Access for this key is limited to rsync to the /allowed/directory/ only. The -wo (write only) option means that rsync will be only allowed to send to the remote machine, -ro would only allow reading from the remote system, giving no option would allow transfer in both directions.
On the local side when you give arguments to rsync you must give the remote path relative to the allowed directory, so on A you would do eg.rsync -options /local/path root@B: and not rsync -options /local/path root@B:/allowed/directory/.
To avoid having to deal with further issues relating to RSA keys, I've decided to migrate all my SSH keys to Ed25519.
Potential issues with RSA keys
- Key length growth: Will gradually require more bits to stay secure as compute capacity advances (Current minimum: 2048 bits)
- Not future proof: Potentially vulnerable to breaking by quantum computers
Advantages of Ed25519 (EdDSA) keys: - Performance: Ed25519 is the fastest performing algorithm across all metrics
- Security: EdDSA provides the highest security level as compared to other algorithms with the same key length (Source)
- Dummy proof: No need to specify number of bits when generating keys
- Shorter public keys: No wrangling with unwieldily long public key strings like in RSA 4096-bit
For context, 253 bits EdDSA is equivalent in strength to RSA ~3000 bits. As you can see, Ed25519 blows all other cryptographic algorithms out the water in terms of performance.
SSH tunneling can serve two purposes. One is a point-to-point secure tunnel between two machines (e.g., for Syncthing purposes), and another is to make use of a port you have available when you don’t control the firewall.
Full system compromise possible by peppering servers with thousands of connection requests. //
The severity of the threat posed by exploitation is significant, but various factors are likely to prevent it from being mass exploited, security experts said. For one, the attack can take as long as eight hours to complete and require as many as 10,000 authentication steps, Stan Kaminsky, a researcher at security firm Kaspersky, said. The delay results from a defense known as address space layout randomization, which changes the memory addresses where executable code is stored to thwart attempts to run malicious payloads.
Other limitations apply. Attackers must also know the specific OS running on each targeted server. So far, no one has found a way to exploit 64-bit systems since the number of available memory addresses is exponentially higher than those available for 32-bit systems. Further mitigating the chances of success, denial-of-service attacks that limit the number of connection requests coming into a vulnerable system will prevent exploitation attempts from succeeding. //
The vulnerability affects the following:
- OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.
- Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.
- The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.
- First, open PuTTy.
- For “Host Name” enter the domain name or IP address of the server that will act as the proxy.
- From the “Category” section on the left, scroll to “Connection” > “SSH” > “Tunnels”.
- Enter the local port you want to use for the proxy connection in the “Source port” field. A common choice is “8080”.
- Assuming you picked 8080 for the port, then enter “localhost:8080” (without quotes) as the destination. This tells PuTTY to listen to data sent to it on port 8080 from the same computer putty is running on, and forward it to the remote server.
- Where it says “Forwarded ports”, select “Dynamic”. This enables the SOCKS protocol.
- Now click “add”.
- Go back to the “Session” option in the left panel. Type in a name for this connection under the “Saved Sessions” text box.
- Now click the “Save” so you’ll be able to open the connection later without repeating these steps again.
- Almost done! Just click the “Open” button.
The cybersecurity world got really lucky last week. An intentionally placed backdoor in xz Utils, an open-source compression utility, was pretty much accidentally discovered by a Microsoft engineer—weeks before it would have been incorporated into both Debian and Red Hat Linux. //
It was an incredibly complex backdoor. Installing it was a multi-year process that seems to have involved social engineering the lone unpaid engineer in charge of the utility. //
The sophistication of both the exploit and the process to get it into the software project scream nation-state operation. It’s reminiscent of Solar Winds, although (1) it would have been much, much worse, and (2) we got really, really lucky.
I simply don’t believe this was the only attempt to slip a backdoor into a critical piece of Internet software, either closed source or open source. Given how lucky we were to detect this one, I believe this kind of operation has been successful in the past. We simply have to stop building our critical national infrastructure on top of random software libraries managed by lone, unpaid, distracted, or worse individuals.
Cyberduck for mounting volumes in the file explorer.
Mountain Duck lets you mount server and cloud storage as a disk in Finder on macOS and the File Explorer on Windows. Open remote files with any application and work like on a local volume.
Cyberduck is a libre server and cloud storage browser for Mac and Windows with support for FTP, SFTP, WebDAV, Amazon S3, OpenStack Swift, Backblaze B2, Microsoft Azure & OneDrive, Google Drive and Dropbox.
mustached-dog Seniorius Lurkius
22y
30
Subscriptor
Interestingly enough, "Jia Tan" is very close to 加蛋 in Mandarin, meaning "to add an egg". Unlikely to be a real name or a coincidence. //
choco bo Ars Praetorian
11y
402
Subscriptor++
Performance hit is quite substantial, actually. I have no doubt that this thing would have been detected, eventually. However, it might have happened months from now. Then it would have been everywhere already.
But this is a good thing. A very good thing, actually.
There have been discussions about supply chain attacks, for years. Decades, actually. We used to call it "poisoning the well" many years ago. But no matter how much we talk about it, it was all theoretical. I mean, people even assumed that compilers have been backdoored many years ago. But noone was going to spend this much effort just to show that it was possible and to make people accept the possibility. So not much was really done about it.
Until now.
Now we are already seeing changes being made to OpenSSH that would have not been possible few months ago. Native systemd notification integration is already been developed (since 30th of March), so no need for libsystemd linking anymore. It will take some time to get integrated but it will happen. We are seeing people understanding that there is absolutely no need to have binary blobs in source repositories (except rare cases, of course, but those are going to be audited even more now). Checking source repositories against tarballs have been done before, many times. But obviously it wasn't good enough or often enough. That will change as well. People being dicks to maintainers are going to get greeted with "go fuck yourself" now, without a second thought. It will be extreme but it will be safer. For eternity I was terrified of compiling software myself because every time I invoked "./configure ..." I would think "fuck knows what is going on there right now". I did occasionally check scripts, I would grep for unexpected things but I was aware I'd never detect a very skilled attacker, like this one. Now there is going to be much more checking of autoconf/make/CMake/etc files in source repos. It won't be easy to detect things, but it will be easier. More eyes will be put on sources. For example, I am going to pick a random smaller project and just read the commit history, look for oddities, etc. Not because I expect to find something but I want to see what else should be looked at, etc. Eventually, I might end up with toolset that might help speed this process up. So there will be at least one more set of eyes looking at sources. I imagine that companies/organizations with more resources are going to put tons of effort into automating all this. So yeah, xz backdoor is actually a good thing, in a very bizarre way.
Also, I can't hunt all the references at the moment but I believe it was certificate (not the SSH key) that is used as a vector of attack, because certs are checked early and no configuration options will disable that check, while it wouldn't be the case with keys. A change to OpenSSH has already been suggested so OpenSSH will only get more secure because of this and one less vector of attack is now available.
Amount of skill and time/effort invested in this is mind blowing. I don't think people outside security really comprehend the skill/time involved here, this was insanely well executed attack. My first thought was "This had to be TURLA" because it was insanely smart and whoever did this had lots of patience. This does not (and will not) happen often.
So yeah, we were incredibly lucky that a Postgres developer caught it early.
However, it is mind blowing how many times security incidents have been detected by looking at CPU/RAM usage on systems, it is really no surprise that this is how xz backdoor got detected.
PuTTY for Windows saves all sites and configuration in Windows Registry.
Batch file to export sites and configuration from Windows Registry to a .reg file:
@echo off
::
:: export putty sites in ANSI mode
::
regedit /ea "o:\my documents\.ssh\putty-ini.reg" HKEY_CURRENT_USER\Software\SimonTatham\PuTTYTo later import, right-click on putty-ini.reg and select "import" or "merge".
Terrapin isn't likely to be mass-exploited, but there's little reason not to patch.
Novel Terrapin attack uses prefix truncation to downgrade the security of SSH channels.
Although ssh -D is an option, it’s a bit overkill because connections aren’t limited to just a single port – it’s allowing apps on the client to connect to any port and/or network interface on the remote host.
A simpler and more secure option is to forward just the required port. Then you won’t need to change proxy settings and/or rely on web browser add-ons.
For OpenSSH, the command syntax is as follows:
ssh -L local_port:host:host_port user@remote_hostFor example…
ssh -L 1234:127.0.0.1:8384 logmein@10.10.10.10ssh– OpenSSH client.-L– Forward a local network port.1234– A locally available network port to listen on.127.0.0.1– Host to forward connections to.8384– Network port on the specified host being forwarded to.logmein@10.10.10.10– Remote host to tunnel to, logging on aslogmein.
Now choose any suitable web browser – no proxy changes and/or proxy add-ons required – and go to http://127.0.0.1:1234/.
Connections to local port 1234 are tunneled thru remote host 10.10.10.10 and forwarded to 127.0.0.1:8384 where Syncthing’s built-in web server is waiting for connections.
For convenience, add the following OpenSSH configuration block to ~/.ssh/config:
Host syncthing-webui
LocalForward 127.0.0.1:1234 127.0.0.1:8384
HostName 10.10.10.10
User logmeinThen to open the SSH tunnel, refer to the host alias:
ssh syncthing-webui
Fail2Ban uses the file /etc/fail2ban/jail.local and look for the [ssh] section, you can change the port there.
[ssh]
enabled = true
port = sshYou can change the port value to any positive integer.
An error as small as a single flipped memory bit is all it takes to expose a private key. //
Martin Blank Ars Tribunus Militum
gromett said:
I have read it twice and am still not entirely clear.
Does this affect OpenSSH? As I read it the answer is no?
As happens often in cryptographic attacks that at least start out as implementation-specific, the likely answer is "it is not currently known to affect other implementations." Cryptographic techniques always get cheaper, never more expensive, and it is difficult to guarantee that other implementations are not vulnerable through variations of this attack. //
bobo bobo said:
A link in this article, to a Wikipedia page on Man In the Middle attacks, is labeled as a "malory in the middle" attack. But, um, the Wikipedia page does not use the term "malory". I am confused by use of the word "malory".
Typo? Or am I missing something?
It's a less common use, but it's part of the movement in the IT industry to move away from sensitive terms (e.g., master/slave becoming primary/secondary or similar). I've also heard monster-in-the-middle and monkey-in-the-middle, but really, there are no suggested terms that roll off the tongue the way man-in-the-middle does while keeping the MitM shorthand. //
FabiusCunctator Ars Scholae Palatinae
The vulnerability occurs when there are errors during the signature generation that takes place when a client and server are establishing a connection. It affects only keys using the RSA cryptographic algorithm, which the researchers found in roughly a third of the SSH signatures they examined.
A good reason to not use RSA keys if possible. I configure all of my ssh setups to use ED25519 keys by default, with a fallback to RSA if ED25519 support is not available.
You can generate an ED25519 key using the standard OpenSSH package by doing:
ssh-keygen -t ed25519That will generate two files in your ssh key directory ('~/.ssh/' by default): 'id_ed25519' and 'id_ed25519.pub'. The first is your private key (keep it close!), while the second is your public key. Add that to the public key file you deploy to remote servers, and (where supported *) your logins will then use the new ED25519 keypair in preference to RSA ones.
- The 'where supported' caveats are important. While many if not most ssh implementations today (including OpenSSH) support ED25519 keys, there are still a few around that don't. Hence, it's a good idea to maintain both ED25519 and RSA keys and include both in your public key lists. If an implementation does not support ED25519, it will just ignore those keys and use RSA. //
all the tags from https://b.plas.ml
1st-amendment 2nd-amendment 4th-amendment 5th-amendment 9/11 a8 abortion acl adhd afghanistan africa a/i air-conditioning amateur-radio amazon america american android animals anti-americanism antifa anti-semitism antiv antivirus aoip apollo apple appliances archaeology architecture archive art astronomy audio automation avatar aviation backup bash batteries belleville bible biden bill-of-rights biology bookmarks books borg bush business calibre camping capitalism cellphone censorship chemistry children china christianity church cia clinton cloud coldwar communication communist composed computers congress conservatives constitution construction cooking copyleft copyright corruption cosmology counseling creation crime cron crypto culture culture-of-death cummins data database ddt dd-wrt defense democrats depression desantis development diagrams diamonds disinformation diy dns documentation dokuwiki domains dprk drm drm-tpm drugs dvd dysautonomia earth ebay ebola ebook economics education efficiency electricity electronics elements elwa email energy engineering english environment environmentalism epa ethernet ethics europe euthanasia evolution faa facebook family fbi fcc feminism finance firewall flightsim flowers fonts français france fraud freebsd free-speech fun games gardening genealogy generation generators geography geology gifts git global-warming google gop government gpl gps graphics green-energy grounding hdd-test healthcare help history hollywood homeschool hormones hosting houses hp html humor hunting hvac hymns hyper-v imap immigration india infosec infotech insects instruments interesting internet investing ip-addressing iran iraq irs islam israel itec j6 journalism jumpcloud justice kindle kodi language ldap leadership leftist leftists legal lego lgbt liberia liberty linguistics linux literature locks make malaria malware management maps markdown marriage mars math media medical meshcentral metatek metric microbit microsoft mikrotik military minecraft minidisc missions moon morality mothers motorola movies mp3 museum music mythtv names nasa nature navigation navy network news nextcloud ntp nuclear obama ocean omega opensource organizing ortlip osmc oxygen paint palemoon paper parents passwords patents patriotism pdf petroleum pets pews photography photo-mgmt physics piano picasa plesk podcast poetry police politics pollution pornography pots prayer pregnancy presentations press printers privacy programming progressive progressives prolife psychology purchasing python quotes rabbits rabies racism radiation radio railroad reagan recipes recording recycling reference regulations religion renewables republicans resume riots rockets r-pi russia russiagate safety samba satellites sbe science sci-fi scotus secularism security servers shipping ships shooting shortwave signal sjw slavery sleep snakes socialism social-media software solar space spacex spam spf spideroak sports ssh statistics steampowered streaming supplement surveillance sync tarsnap taxes tck tds technology telephones television terrorism tesla theology thorium thumbnail thunderbird time tls tools toyota trains transformers travel trump tsa twitter typography ukraine unions united.nations unix ups usa vaccinations vangelis vehicles veracrypt video virtualbox virus vitamin vivaldi vlc voting vpn w3w war water weather web whatsapp who wifi wikipedia windows wordpress wuflu ww2 xigmanas xkcd youtube zfs