Setting Up Your VPS with Gemini CLI or Claude Code

Multi · April 11

@ovexro said:
The people who are developing Claude Code are telling us to use it and that the AI's powerful models are reliable and safe.

stxsh · April 11

when AWS took over the industry -- everyone said the same. I saw $2m/month on EC2 in one of our accounts a few weeks ago (lead dev at major corp). They owned us and we're still auditing/cleaning the influx of projects that were just so "easy" to spin up. We don't even know what half these projects are doing or why anymore.

Claude, Cursor, etc.. will likely do the same. These requests/tokens are being used like it's oxygen.

I see similar issues down the line, and the cost is the workforce. The goal behind the AI push is to do more with less. They don't know how to execute that properly, but they're going to try.

Unfortunately -- this is what will happen in every industry. I'm not sure we can "fight" it, esp. when it benefits us as individuals, corps are just an extension of us.

EDIT/TLDR: Prepare for a new kind of gold rush.

xvps · April 11

@ovexro said:

@Fubukibox said: what? I just use the terminal. Who the hell uses Gemini CLI or Claude code to SSH into your server? You mean letting the AI have access to your server directly?

Yes, either Gemini CLI or Claude Code can be installed on your VPS, and the AI agents can do stuff in your place—executing commands, configuring files if you grant them permission (they ask every time before a command is executed in the terminal).

People on LET love AI sysadmins and support agents, just look at how many buy services and happily repost AI-generated support replies to score free extra months in this thread:

https://lowendtalk.com/discussion/215668/pulsed-media-celebrating-vaeinaemoeinen-1tb-9-99-year-storage-box-1tb-for-0-83-month/p1

itachikonoha · April 11

@ovexro said:

@stxsh said: When you DO vibe code, ask the agents to create bespoke config driven frameworks. This gives you something you can actually review later and maintain. If you have it hack in "features" left and right, it'll butcher its own code constantly and be a mess for anyone to fully understand E2E and maintain.

Thank you so much! I've been advised otherwise here by many, telling me that vibe coding is wrong, that the AI is blind, or whatever. All sorts of discouraging reasons.

People weren't telling me how to set proper parameters for closing loops and removing dead ends. Or they did not tell me how to create a proper memory system that covers everything.

The people who are developing Claude Code are telling us to use it and that the AI's powerful models are reliable and safe. So why are so many people here discouraging me from using AI instead of giving me relevant advice on how to use it properly?

People are discouraging you because they are JEALOUS of you. You could do wonders with claude AI which those haters can't even think of doing it in their dreams! When you excel something to the point where it becomes threatening for others, they will start to pull you down.

ovexro · April 11

@itachikonoha said: People are discouraging you because they are JEALOUS of you. You could do wonders with Claude AI, which those haters can't even dream of doing! When you excel in something to the point where it becomes threatening to others, they will start to pull you down.

I wish I knew you in real life. Your advice seems legit. You know more than setting up a VPS or coding. You know life stuff. Damn!

DataWagon · April 11

@forest said:

@ovexro said: Mistakes are to be made so that we can learn.

So you realized that slopbots produce insecure code no matter how you prompt them?

Did you try telling it “make no mistakes” ?

DejavuMoe · April 11

@forest said:

@ovexro said: The agent recommended closing the open SSH port 22 (and other ports that do not support TLS/SSL) so I can rely on more secure ones, switching to a new port (e.g., 34221)

Perfect example of the AI giving you insecure advice. Using a high port for SSH is common advice, but it's flawed advice due to the fact that a high port is not privileged, i.e. anyone can bind to it. This allows a malicious local process to bind to SSH's port before it does and attempt to exploit clients. So congrats, you've essentially given every single unprivileged process CAP_NET_BIND_SERVICE as far as SSH is concerned, and you declared it safe because the AI told you.

You should just leave SSH on 22 and use pubkey authentication or, if you just don't want log spam, use nearly any free port below 1024 or use DNAT so SSH still binds to port 22 but you can access it from some other port like this:
chain prerouting_nat {
        type nat hook prerouting priority dstnat; policy accept;
        tcp dport 34221 redirect to :ssh
}
As a bonus, you won't be "leaking" your SSH port via statistical analysis of random outgoing source ports or running the risk of SSH failing to start due to 34221 being within the default net.ipv4.ip_local_port_range of 32768 to 60999.

But you didn't know that because the AI didn't tell you.

Thanks! that’s so cool！

James404_ · April 11

@itachikonoha said:

@ovexro said:

@stxsh said: When you DO vibe code, ask the agents to create bespoke config driven frameworks. This gives you something you can actually review later and maintain. If you have it hack in "features" left and right, it'll butcher its own code constantly and be a mess for anyone to fully understand E2E and maintain.

Thank you so much! I've been advised otherwise here by many, telling me that vibe coding is wrong, that the AI is blind, or whatever. All sorts of discouraging reasons.

People weren't telling me how to set proper parameters for closing loops and removing dead ends. Or they did not tell me how to create a proper memory system that covers everything.

The people who are developing Claude Code are telling us to use it and that the AI's powerful models are reliable and safe. So why are so many people here discouraging me from using AI instead of giving me relevant advice on how to use it properly?

People are discouraging you because they are JEALOUS of you. You could do wonders with claude AI which those haters can't even think of doing it in their dreams! When you excel something to the point where it becomes threatening for others, they will start to pull you down.

are we fr

JohnnySac · April 11

@forest said:

@ovexro said: The agent recommended closing the open SSH port 22 (and other ports that do not support TLS/SSL) so I can rely on more secure ones, switching to a new port (e.g., 34221)

Perfect example of the AI giving you insecure advice. Using a high port for SSH is common advice, but it's flawed advice due to the fact that a high port is not privileged, i.e. anyone can bind to it. This allows a malicious local process to bind to SSH's port before it does and attempt to exploit clients. So congrats, you've essentially given every single unprivileged process CAP_NET_BIND_SERVICE as far as SSH is concerned, and you declared it safe because the AI told you.

You should just leave SSH on 22 and use pubkey authentication or, if you just don't want log spam, use nearly any free port below 1024 or use DNAT so SSH still binds to port 22 but you can access it from some other port like this:
chain prerouting_nat {
        type nat hook prerouting priority dstnat; policy accept;
        tcp dport 34221 redirect to :ssh
}
As a bonus, you won't be "leaking" your SSH port via statistical analysis of random outgoing source ports or running the risk of SSH failing to start due to 34221 being within the default net.ipv4.ip_local_port_range of 32768 to 60999.

But you didn't know that because the AI didn't tell you.

I wouldn't call it totally insecure advice (aside from the part of using a port in the ephemeral range). Using a non-22 port (below the local range) is a great way to reduce constant bot scans and auth attempts hitting port 22, and constant Fail2ban ssh bans. Bots hit port 22 on every IP but not every port on every IP so you prevent most random garbage.

An unprivileged process can bind to an unprivileged port but that only matters if a malicious local process is already running on your server and manages to grab the port before sshd. At that point, you already had a local compromise problem which using a non-22 port didn't cause.

suyadi92 · April 11

@James404_ said:
are we fr

yes 🗿🗿🗿

layer7 · April 11

Hi,

from my experience if its getting more complicated things, for example to realize something with juniper's junos, AI is giving solutions that would not work / close to nonsense sometimes.

For simple things ( writing a script in bash or python ) it is doing quiet a fine job.

I was once lazy to change the config of some grafana server dashboard's definitions. Claude did a very well job there. Perfect to save typing work...

But you should actually define some global rules how claude has to work and you should actually check what claude is doing, and also my trust is not enough to let it on the important infrastructure.

But from the point of capability, AI will do common tasks for you in a fully sufficient way.

emgh · April 11

Don’t have it do it directly, but feel free to have it help you with your Ansible playbooks. Best of both worlds.

Jord · April 11

Ansible is prem, what are we vibing today?

stable_genius · April 11

Did you you read the ToS? Copilot says it's "For Entertainment Purposes Only" but similar warnings are common across the industry. Did you you read the ToS?

But hey, Russian roulette is a great game to play if you're into that sort of thing so go ahead, I trust you will not hurt anyone but yourself. Stay Strong.

stable_genius · April 11

@forest said:

@ovexro said: The agent recommended closing the open SSH port 22 (and other ports that do not support TLS/SSL) so I can rely on more secure ones, switching to a new port (e.g., 34221)

Perfect example of the AI giving you insecure advice. Using a high port for SSH is common advice, but it's flawed advice due to the fact that a high port is not privileged, i.e. anyone can bind to it. This allows a malicious local process to bind to SSH's port before it does and attempt to exploit clients. So congrats, you've essentially given every single unprivileged process CAP_NET_BIND_SERVICE as far as SSH is concerned, and you declared it safe because the AI told you.

You should just leave SSH on 22 and use pubkey authentication or, if you just don't want log spam, use nearly any free port below 1024 or use DNAT so SSH still binds to port 22 but you can access it from some other port like this:
chain prerouting_nat {
        type nat hook prerouting priority dstnat; policy accept;
        tcp dport 34221 redirect to :ssh
}
As a bonus, you won't be "leaking" your SSH port via statistical analysis of random outgoing source ports or running the risk of SSH failing to start due to 34221 being within the default net.ipv4.ip_local_port_range of 32768 to 60999.

But you didn't know that because the AI didn't tell you.

Spot on, besides changing port numbers is security through obscurity, the AI bot is as hopeless as its user,

Your analysis is excellent, it's such a shame the OP can't understand most of it.

TimboJones · April 11

I made the mistake of using Gemini cli to help organize my iso collection yesterday. It would tell me what it would do and always sounded good, but then I'd check the contents after and find so many nested issues and just fucked things so badly.

It doesn't always do what it says it will do or ends up being what it thinks it will be. It is worse than having an intern on first day of work figure shit out without help.

forest · April 11

@JohnnySac said: I wouldn't call it totally insecure advice (aside from the part of using a port in the ephemeral range)

Yes, I meant the high port in the ephemeral source port range is the issue. Running SSH on, say, port 971 is harmless and a nice way to reduce log spam if it gets annoying. I personally use port knocking to temporarily allow SSH from a specific IP, just to reduce the (already very low) chance of getting hit by a pre-auth RCE or information disclosure issue.

@JohnnySac said: An unprivileged process can bind to an unprivileged port but that only matters if a malicious local process is already running on your server and manages to grab the port before sshd

Or a non-malicious process opens a long-running connection that, by dumb luck, chooses your "random" SSH port to be its random source port before sshd binds to it. You could avoid that by putting it in net.ipv4.ip_local_reserved_ports, but at that point, why not just use DNAT to avoid wasting an ephemeral port?

@JohnnySac said: At that point, you already had a local compromise problem which using a non-22 port didn't cause.

That's not necessarily an issue on an appropriately sandboxed system. Granted, most people don't harden their systems well and their primary non-root user might as well be root already (I cringe every time I see sudo -i on the same user that blindly runs pipx install), but on a well-hardened system, dropping CAP_NET_BIND_SERVICE does improve security. If I was auditing a system and CAP_NET_BIND_SERVICE was in the system's ambient capability set, I'd absolutely flag that.

forest · April 11

@itachikonoha said:

@ovexro said:

@stxsh said: When you DO vibe code, ask the agents to create bespoke config driven frameworks. This gives you something you can actually review later and maintain. If you have it hack in "features" left and right, it'll butcher its own code constantly and be a mess for anyone to fully understand E2E and maintain.

Thank you so much! I've been advised otherwise here by many, telling me that vibe coding is wrong, that the AI is blind, or whatever. All sorts of discouraging reasons.

People weren't telling me how to set proper parameters for closing loops and removing dead ends. Or they did not tell me how to create a proper memory system that covers everything.

The people who are developing Claude Code are telling us to use it and that the AI's powerful models are reliable and safe. So why are so many people here discouraging me from using AI instead of giving me relevant advice on how to use it properly?

People are discouraging you because they are JEALOUS of you. You could do wonders with claude AI which those haters can't even think of doing it in their dreams! When you excel something to the point where it becomes threatening for others, they will start to pull you down.

Be careful. He's going to believe you.

unsafetypin · April 11

@ovexro said:

@forest said: You should just leave SSH on 22 and use pubkey authentication, or, if you just don't want log spam, use nearly any free port below 1024 or use DNAT so SSH still binds to port 22 but you can access it from some other port like this:

Thank you so much!

I will try other ports as well. I didn't want 22 opened because my IP was bruteforced so many times. My logs were full of "attacks."

Obscurity isn't security. Any automated scanner will just find the ssh listener port on whatever other port you use.

stable_genius · April 12

@ovexro said:

@itachikonoha said: People are discouraging you because they are JEALOUS of you. You could do wonders with Claude AI, which those haters can't even dream of doing! When you excel in something to the point where it becomes threatening to others, they will start to pull you down.

I wish I knew you in real life. Your advice seems legit. You know more than setting up a VPS or coding. You know life stuff. Damn!

You just swallowed something hook, line, and sinker.

I mean both of you.

itachikonoha · April 12

@TimboJones said:
I made the mistake of using Gemini cli to help organize my iso collection yesterday. It would tell me what it would do and always sounded good, but then I'd check the contents after and find so many nested issues and just fucked things so badly.

It doesn't always do what it says it will do or ends up being what it thinks it will be. It is worse than having an intern on first day of work figure shit out without help.

I found Google ai studio better than gemini. It is less chatty and direct to the point.

JosephF · April 13

@itachikonoha said:

@TimboJones said:
I made the mistake of using Gemini cli to help organize my iso collection yesterday. It would tell me what it would do and always sounded good, but then I'd check the contents after and find so many nested issues and just fucked things so badly.

It doesn't always do what it says it will do or ends up being what it thinks it will be. It is worse than having an intern on first day of work figure shit out without help.

I found Google ai studio better than gemini. It is less chatty and direct to the point.

Google AI Studio is, essentially, the Pro version of Gemini (even though it is free), whereas your use of Gemini may have been the free tier.

artxs · April 14

@forest said:
Perfect example of the AI giving you insecure advice. Using a high port for SSH is common advice, but it's flawed advice due to the fact that a high port is not privileged, i.e. anyone can bind to it. This allows a malicious local process to bind to SSH's port before it does and attempt to exploit clients. So congrats, you've essentially given every single unprivileged process CAP_NET_BIND_SERVICE as far as SSH is concerned, and you declared it safe because the AI told you.

This advice is dumber than AI. Any process can bind to an unprivileged port regardless whether sshd is listening on port 22 or not. Exploiting clients? This is like saying having a web server listening on port 8443 allows browsers to be exploited more than servers listening on port 443. Nonsense. "privileged" process? You're still living in 2001.

TimboJones · April 14

@artxs said:

@forest said:
Perfect example of the AI giving you insecure advice. Using a high port for SSH is common advice, but it's flawed advice due to the fact that a high port is not privileged, i.e. anyone can bind to it. This allows a malicious local process to bind to SSH's port before it does and attempt to exploit clients. So congrats, you've essentially given every single unprivileged process CAP_NET_BIND_SERVICE as far as SSH is concerned, and you declared it safe because the AI told you.

This advice is dumber than AI. Any process can bind to an unprivileged port regardless whether sshd is listening on port 22 or not. Exploiting clients? This is like saying having a web server listening on port 8443 allows browsers to be exploited more than servers listening on port 443. Nonsense. "privileged" process? You're still living in 2001.

Not external exploit, but local. So if ssh listened on port 2222 but a malicious program ran BEFORE sshd did, it would take port 2222 and pretend to be your legitimate ssh service, but bad.

That wouldn't happen on port 22 unless the malicious app had root, which is gameover anyway.

gamingarchive · April 14

You may call me crazy, but I do this all the time... so long as you review what the agent is doing 99% of the time the models are good enough not to make any mistakes

Of course I do the initial setup and verify that everything was done correctly, but often saves me a few websearches.

Have used it to setup GitLab, Element, etc. on a few VPS's at this point, even on a friend's VPS. I checked & everything was done correctly, even setup nginx

forest · April 15

@artxs said:

@forest said:
Perfect example of the AI giving you insecure advice. Using a high port for SSH is common advice, but it's flawed advice due to the fact that a high port is not privileged, i.e. anyone can bind to it. This allows a malicious local process to bind to SSH's port before it does and attempt to exploit clients. So congrats, you've essentially given every single unprivileged process CAP_NET_BIND_SERVICE as far as SSH is concerned, and you declared it safe because the AI told you.

This advice is dumber than AI. Any process can bind to an unprivileged port regardless whether sshd is listening on port 22 or not. Exploiting clients? This is like saying having a web server listening on port 8443 allows browsers to be exploited more than servers listening on port 443. Nonsense. "privileged" process? You're still living in 2001.

You clearly don't know what you're talking about. And yes, binding a web server to port 8443 means that an exploited unprivileged process could bind and serve malicious web pages if it binds before your httpd. Both HTTPS and SSH use certificates, thankfully, but plenty of people will click through. Also, remember that the example port given wasn't just a high port, it was also in the ephemeral port range, which means binding could fail even in the absence of a malicious user.

In an ideal world, we'd all be using sandboxing and fine-grained privsep, not just "root" and "a non-root UID", but in the real world, often the only thing stopping an exploited NTP client from binding to port 22 is lack of CAP_NET_BIND_SERVICE.

Now, is this some horrible, critical vulnerability that totally opens up a server to remote attack? No. Exploiting it for more than denial of service would require either operator error (ignoring the fingerprint changing) or a pre-auth RCE against the client, and the ability to compromise some local process. But it's still trivial evidence that the AI's advice to increase security actually decreases it, and attacks of this sort have been used in the real world.

forest · April 15

@gamingarchive said: so long as you review what the agent is doing 99% of the time the models are good enough not to make any mistakes

That you know of.

Not all mistakes have obvious visible effects.

gamingarchive · April 15

@forest said:

@gamingarchive said: so long as you review what the agent is doing 99% of the time the models are good enough not to make any mistakes

That you know of.

Not all mistakes have obvious visible effects.

Fair enough, but I do check everything the agent does

aphex · April 15

@forest said: That you know of.

You're just jealous you don't get side effects.

artxs · April 16

@TimboJones said:
Not external exploit, but local. So if ssh listened on port 2222 but a malicious program ran BEFORE sshd did, it would take port 2222 and pretend to be your legitimate ssh service, but bad.
That wouldn't happen on port 22 unless the malicious app had root, which is gameover anyway.

SSH host is identified by its host key, which the client would warn if it changes. For web servers, TLS certificates identifies the website via its private key. The idea of tying service "legitimacy" to a port number is a boomer's game that should've died long ago.

Apache forks its processes and setuid into "nobody" precisely for safety. It runs as root to bind to port 443 for NO legitimate reason except for some old geezer who believe the number 443 is "privileged" and more special than other numbers.

Howdy, Stranger!

Categories

In this Discussion

Setting Up Your VPS with Gemini CLI or Claude Code

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Setting Up Your VPS with Gemini CLI or Claude Code

Comments