cyberwolfie @ cyberwolfie @lemmy.ml

Posts

35

Comments

422

Joined

2 yr. ago

Do you know if there is any way to check and potentially also block inter-app communications like that?

Thanks - I'll look more into that to see if I can make any rules that would make sense for my use case.

It’s recommended you keep the default port because as soon as your IP is known it takes less than 5 minutes to scan every port for an ssh port

Fair point! I first thought that would be good, as it would discourage all those random connections. My guess is that they won't bother spending 5 minutes on each server, and instead just move on to the next when they fail. But then I realized that I don't really care about those anyway as they're not getting anywhere with their root:mypassword login attempts.

Wayland by default

Having an Nvidia-card, should I be worried about this? So far I've read so many "Nvidia bad, Wayland no work" posts that I have just stayed clear waiting for a final confirmation that everything is smooth sailing.

I am not sure what you intention was with your reply, so maybe I am misreading it.

"... that respects your privacy" is most of the post title. I was simply asking whether a keyboard application could be privacy disrespecting, if it doesn't have network access. It was genuine question that I want to learn the answer to, and I was hoping that somebody might be able to provide a sensible answer.

Edit: oh, you’re talking about the high port OP is wondering about. That’s just the source port, which is chosen randomly by the client OS when making a connection. Using port 22 (or any other port below 1025) as a source port would require root privileges on the client and would also conflict with the SSH server that could be running there. Still, it has nothing to do with SSH “moving connections over”

Ah, I see, so the port numbers shown in auth.log are all client side ports. I guess I thought that the listening port would be in the log and assumed that the port listed there would be it, but when I read the lines again, it clearly says "from ip.ad.dr.ess port 12345"

Alright, cheers - I'll leave it be as well then :)

Yes.

Just keep in mind that security through obscurity is not considered secure in itself.

Do you consider it to not be a helpful measure to take at all?

I have fail2ban configured - since it is reading from the auth.log, I guess I would not have to make any changes to the configuration there to have it work with a new port?

Yes that’s the right way to block root login. An added filter you can use the ‘match’ config expression to filter logins even further.

Not sure what you meant about the 'match' config expressions here. Could you elaborate a bit further?

If you’re on the open network, your connection will be heavily hit with login attempts. That is normal. But using another service like Fail2Ban will stop repeated hits to your host.

Hehe, yeah, I've noticed... The reason I get a little anxious whether I did this correctly, is that 95% of the login attempts are to root, so I want to make sure it is disabled. I have set up Fail2Ban, but I am using default settings, which may be a bit laxer than they need?

I've also been advised and considered moving to ssh keys, but I have not gotten to that yet.

Ssh listens on port 22, as soon as a connection is made the host moves the connection to another port to free up 22 for other new connections.

Makes sense. One question that comes from this is: is it possible to disable that? I would never need two ssh-logins at the same time on my server. And the second question is what I asked above regarding whether I should change the port ssh listens to in order to reduce unwanted malicious login attempts?

Yes, this is something I did when setting up the server some time ago, and as a step in the process I rebooted the system after changing the config.

Ok, thanks - so if I understand correctly then, it is listening on port 22 as a default, and not accepting traffic on any port.

That brings of the question: wouldn't I be better off changing the SSH-port? And is that so easy as to uncomment the #Port 22 line in the config file and changing the port number to something random, and saving that somewhere? Would I then be able to connect by running ssh myuser@mydomain.com:, or would I need to do anything else to successfully connect?

But maybe that’s because I’m from Germany. Here the concept of privacy is something most people like, at least in real life and in untechnical situations.

My experience from interacting with Germans is that you are above-average privacy conscious, which I find very admirable and gives me some level of hope that it is possible to gain some general awareness on these topics also in my country and elsewhere. Why do you think it is so?

Genuine question: is there any way for any keyboard application to be privacy disrespecting if their internet access is blocked off by a firewall?

Never heard that song. For me, the most famous number would be 32 16 8.

Tested with four different machines, one running Linux, two using Windows 10 and one with macOS. Seems to be a codec issue where Linux and Windows defaulted to SBC and macOS to AAC (where it did not occur). Changing to LDAC on Linux helped, although I am certain I had issues with this before with that codec. On Win10 I have no wiggle room as it is my work machine, and I seem to need third party software installed to change.

Don’t you love when you give in and go to get help for something and you can no longer reproduce it after you ask?

It's almost like it's a law of nature...

Rechecked this now, and it's at about 5% now. The statistics seem a bit weird to me, unless there are some big seasonal changes. Your 12% was recorded in June and July. Maybe with less business activity during these months, the Windows share plummets in favor of home users who are more prone to use Linux.

Hm, yeah. Just checked in macOS, and it is using AAC there. So lack of AAC on my Linux device would mean it is not available here for some reason then I guess, and not an issue with the headset?

I can't seem find a way to check the same on Windows 10 without using a third-party tool, and since this is a work computer, that is not an option for me. My guess is then that it uses SDC. Seems like AAC is supported natively in Windows 11 though, and the device is scheduled for a Win 11 install soon. Hopefully that will resolve the issue for me during work hours.

For now it seems to work better under Linux with LDAC though, which is my main use case. I swear I've had issues with this before, but I just streamed an entire album of high-bitrate FLAC tracks without issue now. Hopefully it stays this way.

That looks very similar to mine, except I don't have AAC and aptX. I guess the WH1000MX5 only supports SDC and LDAC? As far as I know, I need to use the Headset Head Unit to get microphone input. After a system update some time back, it would switch automatically if I e.g. was on a Signal call. Prior to this, I would have to switch manually to get microphone input.

By the way, I am not entirely sure if I am running PulseAudio or PipeWire, as I get the confusing output below, but it seems to be PulseAudio. Is it likely to improve things if I were to switch to PipeWire?

    
$ pactl info | grep "Server Name"
Server Name: PulseAudio (on PipeWire 0.3.80)

  

As for my Windows issue, it seems LDAC is not natively supported in Windows 10, so I guess it is using SDC. Could my problems simply be that I am trying to stream a too high bitrate? I will need to recheck my settings for stream quality.