gyptazy.ch is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.

This server runs the snac software and there is no automatic sign-up process.

Admin email
contact@gyptazy.ch
Admin account
@gyptazy@gyptazy.ch

Search results for #ssh

Hella »
@unixwitch@social.tchncs.de

@conorh
Other protocols are also possible, e.g. you can edit files via scp

vim scp://user@remoteserver.example.org//home/user/remotefile.txt

Peter N. M. Hansteen »
@pitrh@mastodon.social

adfichter 🖋 »
@adfichter@chaos.social

Wer ist "Jia Tan"? Eine interessant zu lesende Spurensuche von
@marcel anhand von technischen Indizien zu Zeitzonen, Verhalten, Motive, Aufwand.

dnip.ch/2024/05/14/spurensuche

Marcel Waldvogel »
@marcel@waldvogel.family

@xtaran Aber eben: greift nur an; und nur in bestimmten Setups (und muss dazu die Systembibliothek sein, nicht eine händisch nachinstallierte für ein Projekt).

Marcel Waldvogel »
@marcel@waldvogel.family

Wir sind dieses Wochenende nur durch unglaubliches Glück und extrem knapp an wohl einer der grössten Katastrophen rund um die globale IT-Sicherheit vorbeigeschrammt.

Phuh! Doch — was ist eigentlich passiert? Wie konnte das überhaupt geschehen? Und was können (und müssen) wir tun, um dies zukünftig zu vermeiden?

Und: Danke an die ganzen IT-Helden, die dies an diesem langen Wochenende für uns getan haben.

dnip.ch/2024/04/02/xz-open-sou

Marcel Waldvogel »
@marcel@waldvogel.family

Der Angriff hatte zum Ziel, Abermillionen von Servern weltweit für die unbekannten Angreifer zu öffnen. Was diese mit den Früchten der Vorbereitung der letzten 3 Jahre dann hätten erreichen wollen, das werden wir wohl nie erfahren. Aber die potenziellen Auswirkungen auf Abermillionen von Nutzerinnen, ihren Daten aber auch die Wirtschaft und Stabilität von ganzen Ländern hätten dramatisch werden können.

dnip.ch/2024/04/02/xz-open-sou

Marcel Waldvogel »
@marcel@waldvogel.family

Durch Good-Cop/Bad-Cop-Taktiken wurden Softwareentwickler dazu gedrängt, subtil versteckte Sicherheitslücken einzubauen. Wie können wir das zukünftig vermeiden?
.
1️⃣ Vereinfachung/Reduzierung von Programmen und Abhängigkeiten
2️⃣ Mehr Wertschätzung und Unterstützung für die Open-Source-Entwickler
3️⃣ Bessere Kontrolle, aber ohne Belastung für die Entwickler
4️⃣ Angewandtere Ausbildung

Was sind eure Ideen dazu? Freue mich auf Feedback!


marcel-waldvogel.ch/2024/04/02

Marcel Waldvogel »
@marcel@waldvogel.family

«Die Feiertage. Die ganzen IT-Abteilungen feiern mit der Familie… Die ganzen IT-Abteilungen? Nein! Eine von unbeugsamen Open-Source-Enthusiasten bevölkerte Mailingliste hört nicht auf, den Eindringlingen Widerstand zu leisten.»


dnip.ch/2024/04/02/xz-open-sou

Axel ⌨🐧🐪🚴😷 | R.I.P Natenom »
@xtaran@chaos.social

Worked on (github.com/xtaran/dist-detect) today, added signatures for (21-40; source: bodhi.fedoraproject.org/update) and for / SLES (11-15; source: software.opensuse.org/package/) confirmed by some real-life examples, as well as some other maintenance chores.

While digging through @shodan results for examples I found a host with OpenSSH 3.4p1 and "Apache/1.3.29 (Linux/SuSE)", i.e. a SLES 8.1 from 2002. 🙈

ttyS1 »
@ttyS1@bsd.network

adingbatponder »
@adingbatponder@fosstodon.org

nixCraft 🐧 »
@nixCraft@mastodon.social

Every version of the PuTTY tools from 0.68 to 0.80 inclusive has a critical vulnerability in the code that generates signatures from ECDSA private keys. Tthe effect of the vulnerability is to compromise the private key chiark.greenend.org.uk/~sgtath

Simon Tatham »
@simontatham@hachyderm.io

We've released version 0.81. This is a SECURITY UPDATE, fixing a in ECDSA signing for .

If you've used a 521-bit ECDSA key (ecdsa-sha2-nistp521) with any previous version of PuTTY, consider it compromised! Generate a new key pair, and remove the old public key from authorized_keys files.

Other key types are not affected, even other sizes of ECDSA. In particular, Ed25519 is fine.

This vulnerability has id CVE-2024-31497. Full information is at chiark.greenend.org.uk/~sgtath

GaryH Tech »
@garyhtech@mastodon.bsd.cafe

NEW VIDEO - How can I slow down the attacks on my FreeBSD Server?

youtu.be/Jh_roKrqGiU?si=cCa9CK via @YouTube

0 ★ 0 ↺

gyptazy »
@gyptazy@gyptazy.ch

is finally about to launch!

But it also needs something like a self-service portal in long-term. However, for the website I stick to my self-written engine - I guess that fits pretty will here when it's only about serving , & .

This being said, I don't want to write a self-service portal for the web and thought about a service where you just login and can perform several actions like PTR, snapshots, system reset etc.

Currently, I only implemented the user management from an "admin" perspective. A sandbox style can be seen here:

ssh -p 2222 boxybsd@2001:470:54d7:1337::2
Password: create

It's a self-written sshd alike service which communicates with the API and some other bins. Die user login can be done by pub key and pw auth. Feel free to give it a try, it's a sandbox mode on a sandbox vm.

adingbatponder »
@adingbatponder@fosstodon.org

@mttaggart Does this mean that one should never allow inward as ? This thread seems to say ssh as root should be inherently forbidden. stackoverflow.com/questions/18

Stefano Marinelli »
@stefano@mastodon.bsd.cafe

Uncommenting the "block in all", sending a pfctl -f /etc/pf.conf - noting in that precise moment that I didn't explicitly pass ssh - being closed out of my own server...done! ✅

Stefano Marinelli »
@stefano@mastodon.bsd.cafe

This is huge: Backdoor in upstream xz/liblzma leading to SSH server compromise

openwall.com/lists/oss-securit

scy »
@scy@chaos.social

Eek. Apparently liblzma (part of the xz package) has a backdoor in versions 5.6.0 and 5.6.1, causing SSH to be compromised.

openwall.com/lists/oss-securit

This might even have been done on purpose by the upstream devs.

Developing story, please take with a grain of salt.

The 5.6 versions are somewhat recent, depending on how bleeding edge your distro is you might not be affected.

Felix Palmen 📯 »
@zirias@techhub.social

@jhx For writing some kind of "howto", I'll have to find a sane scope ... otherwise there would be just too much to describe I guess 😮

I could of course assume you already have

- network segmentation with a
- a working "domain" setup with a directory and (e.g. , but could be with as well)
- (virtual) machines providing (with in case of or )
- a working mechanism to distribute X.509 (I request them from using and distribute them with simple shell scripts using special-purpose restricted keys)

With all that in place, it would "just" be describing the setup of in a , enabling on all connection paths...

Felix Palmen 📯 »
@zirias@techhub.social

@jhx For writing some kind of "howto", I'll have to find a sane scope ... otherwise there would be just too much to describe I guess 😮

I could of course assume you already have

- network segmentation with a
- a working "domain" setup with a directory and (e.g. , but could be with as well)
- (virtual) machines providing (with in case of or )
- a working mechanism to distribute X.509 (I request them from using and distribute them with simple shell scripts using special-purpose restricted keys)

With all that in place, it would "just" be describing the setup of in a , enabling on all connection paths...

Stéphane Bortzmeyer »
@bortzmeyer@mastodon.gougere.fr

Let's follow the agenda datatracker.ietf.org/meeting/1

First, v3

(I hear people chat and laugh during the reminder of the Code of Conduct.)

Dominik Zajac »
@banym@bsd.network

Which algorythms for authentication with should we trust in 2024 for the next few years? Is with the corresponding key length still the order of the day or are the signs pointing to for everything?

Seán Fobbe »
@seanfobbe@fediscience.org

Question for the git and infosec crowd:

Do you prefer fine-grained personal access tokens (PAT) or secure shell (SSH) authentication for GitHub etc.? Do you have strong feelings about either?

Happy to be pointed to additional resources, my initial searches just turned up vague and poorly LLM-written blog posts...

Santiago Lema »
@santiago@masto.lema.org

TIL that for some reason unlike on Linux, FreeBSD, and even Haiku a session on Mac doesn’t setup the path automatically when you execute a command on start.

So if you want to launch tmux on Mac from ssh you must source your profile first like this (otherwise it won’t find tmux in the homebrew path):

ssh user@192.168.0.33 'source ~/.zshrc; tmux new-session -A -s "SessionName" '