Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Shells Virtual Desktop
BMail.ag - Secure Email Service
Server.net
CPLicense.net
VPS Server
Buy VPN
Vultr
VMs for AI
HostDare
ReliableSite White-Label Dedicated Hosting for Resellers
InterServer VPS
BMail.ag - Secure Email Service
Best VPN
High-Performance Bare Metal Server Solutions
Karvl.com
Server Mania Cloud Hosting
DataWagon Hosting
AlphaVPS Hosting
Evoxt.com
Clouvider
VPS Hosting with NVMe
Residential IPs in the US & 4G Mobile Proxies in EU & US with Unlimited Bandwidth
ReliableSite White-Label Dedicated Hosting for Resellers
Rabisu - Hosting Solutions
Shells Virtual Desktop
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Sharing my initial script for new idling vms.

2»

Comments

  • CloudHopperCloudHopper Member
    edited October 2024

    @jsg

    I engaged with you in good faith, assuming from your fancy tag that you might actually have something useful to share on the subject that I wasn't aware of.

    So when you said "Take that as a puzzle, one worth solving", I actually tested it I Debian 12 to see if there was some interesting default setting that Id missed or something.

    It turns out that you just didn't understand the script, and now you seem to be having a breakdown about zero days in encryption...which is more than a bit off topic when the subject is [supposed] security vulnerabilities introduced by the OP's script.

    However, you evidently don't have anything useful to add to this conversation and you seem ill equipped to admit you simply misunderstood the script and were mistaken so I'll just leave you to your ravings at this point

  • jsgjsg Member, Resident Benchmarker

    @CloudHopper said:
    @jsg

    I engaged with you in good faith, assuming from your fancy tag that you might actually have something useful to share.

    Thank you! So do I (usually).

  • @jsg said:
    Good luck with your blind trust in SSH (but making the server more sakkure anyway via bash) on debian and friends. You obviously are true masters of sakkurity. Shall I bow to you?

    You really need to take a break from the internet...

    Thanked by 1TimboJones
  • You've forgot to put endlessh on port 22 after moving ssh somewhere else.
    Infinite fun

  • @egoror said:
    You've forgot to put endlessh on port 22 after moving ssh somewhere else.
    Infinite fun

    Would it still work?

    I've heard that bots became smarter these days and disconnect after 10-20 seconds of waiting.

  • tentortentor Member, Host Rep

    @DataRecovery said:

    I've heard that bots became smarter these days and disconnect after 10-20 seconds of waiting.

    Not all, but they are. The longest tarpitted connections I've seen are at 23/tcp (I guess this is targeted by telnet-seeking bots).

  • This is for idling? Fail.

    Pretty much the only thing you really need to do (to idle) is enable automatic security updates.

  • @jsg said:
    @CloudHopper @egoror

    OK, So you blindly rely on SSL/SSH being "absolutely sakkure!" - which I find a bit funny, as OP's script is expressly for debian, which has an, ... uhm, not exactly stellar track record re SSH.

    Also, why then e.g. passwd -d root && passwd -l root when NOBODY except legitimate users (well, actually not really) can SSH into the system?

    So, no matter how "confidently wrong" and "condescending" you may find it/me I'll stay by what I said: "Btw. I do not so much look at what's written and done but rather whether I detect typical idiot attempts." I admit one mistake though: I didn't mention attempts based on simply copying and possibly adapting some script found on the internet. Apologies, I should have been more careful.

    Being at "confidently wrong", how many potential 0-days in reference implementations of relevant and used crypto have you found so far? How many thousands of lines of crypto code have you written? How many crypto algorithms have you implemented and/or speed or space optimized? How many of those can fully saturate a 40 Gb/s line on a single X86-64 core?

    Good luck with your blind trust in SSH (but making the server more sakkure anyway via bash) on debian and friends. You obviously are true masters of sakkurity. Shall I bow to you?

    Many of us work with people who know wtf they are talking about. You don't talk like any of those people. If people talked like you in many companies, they'd be fired. You work for the government, don't you?

  • Too much for idling, At least for Security

    (Me) - [through VPN] ---- (Jump Servers: accepts ssh connection from VPN and + OTP auth + file2ban) - (Idling Server: accepts ssh connection from Jump Servers).

  • tjntjn Member

    @raindog308 said:

    @Arirang said: Original script written by me includes ansible user and pubkey. Initial jobs for using ansible takes lots of time. That's why I wrote this like this

    Yeah, the ideal in my mind is to have an SSH key added during provisioning, so you can run ansible immediately afterward. If the provider doesn't offer that, then you need a "prep for ansible" step first which is a hassle.

    I handle this by having a small bash wrapper that calls a simple bootstrap role in ansible that adds my management user + ssh keys. That host is then ready to be provisioned by my larger ansible playbooks.

  • Probably kinda personal preferences but i more like
    1. Use URL instead write public key on shell script (like setup-alpine), so when someday you need rotate ssh key, its kinda easy just update file on URL provided
    2. Disable sudo user to input password kinda defeat purpose second-layer security just in case your private key / ssh auth was compromise.
    3. It would be nice it on lowest possible shell script like sh
    4. And as always, add running yabs every 15 minutes for idling

    #!/bin/sh
     
    LOCK="/tmp/yabs.idling"
    if [ -f "$LOCK" ]; then
         exit 1
    fi
     
    touch "$LOCK"
    curl -sL yabs.sh | bash
    rm -f "$LOCK"
    

    save to /usr/local/bin/yabs and place it on crontab ((crontab -l; echo "*/15 * * * * /usr/local/bin/yabs") | crontab -)

  • @tentor said:

    @DataRecovery said:

    I've heard that bots became smarter these days and disconnect after 10-20 seconds of waiting.

    longest tarpitted connections I've seen are at 23/tcp (I guess this is targeted by telnet-seeking bots).

    Quite possible.

    I'm also constantly getting lines like debian sshd[76882]: Bad protocol version identification '\003' from 45.40.142.108 port 53799 in my ssh log.

Sign In or Register to comment.