EarthBoundX5

I figured this was the case, just wanted to make sure. My serverconfig.xml has persistent profiles set to true.

Yes, I was able to join perfectly fine. He was not. Yes, when deleting the profile I deleted all 3 files and double checked now and confirmed with certainty it was from the correct world. I'll see if he can run the clean up process tomorrow. I'm assuming retaining the single player saves is just a matter of backing them up and restoring? Or does cleaning destroy more? Should note, we did verify game files via Steam. Fair point, but we've been playing for years. He's also using Linux for reference, but this is not new and has been his process for at least the last 2 years since he cut ties with Windows (lucky man, haha).

My friends and I have been playing 7 Days to Die on a dedicated server for years now without any issues. However, we recently encountered an issue that we're unable to find much information on and no fixes have worked. I can login fine, but when my buddy logs in he is presented with the following error: Server Disconnected You: A user from your account is already playing on this server! Background / Attempts to Fix 1. We both upgraded our clients to A20.1. 2. I upgraded the Dedicated Server to A20.1. 3. We both logged in. 4. Buddy Received Error 5. Restarted Dedicated Server software, no change. 6. Restarted Server, no change. 7. Kick command for buddy's Name and ID, no change 8. Deleted buddy's profile on the Server, no change. 9. Restored Server to previous backup prior to upgrading Dedicated Server software. Downgraded clients to A20. No change. 10. Deleted buddy's profile on the Server, no change. At this point, we were out of options and ideas. We had just played fine the weekend before, and no changed were made to the Server in that time. We were thoroughly confused, and the only indication of an issue appears in the logs saying that a player with his Username is already on the server, giving him a new name of Username(1). I have no issues logging in. Here is my buddy's client logs: https://pastebin.com/2TQQ41h7 Here is the terminal window output from the last attempt on the Dedicated Server: https://pastebin.com/uZVAhtnz Here are all the Dedicated Server logs from the last attempt: https://pastebin.com/SrEqLYtK https://pastebin.com/muvGwE05 https://pastebin.com/RTzuVgGh https://pastebin.com/bTS2Yv5m https://pastebin.com/u5e33Qp1 https://pastebin.com/mPXaUmC1 https://pastebin.com/AmZ3kJ3r I have logs from the A20.1 initial test as well, if that is required. Can someone please help me figure this out, until it's fixed, we are unable to play as we normally do. Thanks!

Ya, this is what I was looking for. Since I don't use anything external to manage, I can safely disable for now and revisit when I need it. Thanks! Still unsure from replies though if the telnet session is encapsulated in purely the server commands; and wouldn't open up access to a bad actor to something else. And if anyone at Fun Pimps cares to get more details off this report or not.

If someone gets on my server, that's more of a concern and telnet would be irrelevant. What I'm saying is, if I set a password for telnet in 7 Days to Die, it shouldn't automatically opening up externally vs local loopback without another true/false toggle. And if that is the case, then why not just disable it entirely? Why is it needed, what is it's function for the 7 Days to Die server? Seems like just a vulnerability point?

Ah, so I'm not an idiot for having in enabled...but I am for not reading a comment and putting in a password, haha. Kinda feel that a password shouldn't be the factor in how telnet operates. @Fun Pimps should really add another config line for that IMO... EDIT: Is there any functional reason to have telnet enabled? UGH, I feel stupid...I only looked in the logs folder at root and skimmed around in AppData and ProgramData...logs like this should probably be in a log sub dir...well, one more folder I'll add to Splunk logging.

Confirmed I had telnet enabled in server config. Noted that the default bad passwords and timeout is 10. Probably should have these default much higher. But more so, this still means there was an auth issue at play. And I wonder if the password was cracked with 10 bad attempts and a 10 second cool down, I'm sure it was) or they accessed the telnet service in the 7 Days to Die server via an exploit. This does lead me down a question, what access does one have using telnet offered from the 7 Days to Die server service? Is it contained to just server commands or does it have file access or anything else?

Wasn't sure where this should be posted, as it's not quite support. More of a bug report / what does Fun Pimps want or need from me? I normally shutdown my 7 Days to Die server when not in use. The base VM continues, but the service is shutdown. Today, I realized I'd forgotten to shutdown the server...went to do it, and noticed that about 10 hours after I'd logged off, some weird activity showed up onscreen over a few days and last today. I couldn't copy + paste out of the server console window and I couldn't find the respective logs for the event (if these are even logged?). I have a screenshot, but don't want to have to upload it in order to post it as a link in these forums. Essentially, I saw this, 10 hours after I was done playing... 2021-11-06T10:04:30 45900.107 INF (GSM) GameSparks Disconnected 2021-11-06T13:28:32 58142.189 INF (GSM) GameSparks Connected I didn't think anything of it, but the following lines were much sketchier. I saw the following IPs start and establish Telnet connections. Along with one throwing an exception. 167.71.237.46 104.140.88.42 78.128.112.14 Now, I shouldn't have telnet accessible externally. I might have something enabled in the 7 Days to Die server config, but I'll have to check that. Regardless, I shouldn't have anything unexpected opened external. I checked my Splunk server for these IPs, but only found 2 logs. ControlChannel Open and Closed for FTP services on the VM I host my 7 Days to Die server from. @Fun Pimps, please let me know if there is anything I should be checking or doing or providing to you guys. This on the surface to me indicates a security exploit in the server; even if enabled in a server config...as there should at least be some authentication. Thanks! EDIT: Just to note, I restore from backups to before the first odd console entry. I do have a backup of the day after, but not from after the Telnet events were observed.