Locking yourself out of your server – again

Posted on

Fortunately this is not something I do very often, but when I do, it’s usually good…

One of the things I like to do is have a document with lots of settings and commands I call my cheat sheet – for times that things don’t go to plan.

This time, I was trying to upload some files and I’d set up my server in such a way that I couldn’t upload files to the correct area, but when I did get them in, I had to manually copy them to the correct location afterwards – kind of a different isolating account, a little for extra security. However, as I hadn’t made any adjustments, I basically forgot how I was doing things, and so in the process, I thought that maybe I hadn’t allowed my home IP for SSH.

Well, that was my big mistake. I used Webmin to add the rule of my home IP. It cleared out everything and essentially I was locked out.

I was able to get back in through the server console, but I spent the next few hours trouble shooting what went wrong.

As mentioned, it’s always good to have these thing written down.

I could connect to the server via SSH, however, I was being rejected on connection.

Trying to connnect with this: ssh -p PORT -vvv USER@x.x.x.x

I would get the following, showing where it would suddenly close the connection.

debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to x.x.x.x ([x.x.x.x]:port).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: send packet: type 1
debug1: channel 0: free: client-session, nchannels 1
debug3: channel 0: status: The following connections are open:
#0 client-session (t3 nr0 i0/0 o0/0 e[write]/0 fd 4/5/6 sock -1 cc -1)
debug3: fd 1 is not O_NONBLOCK
Connection to x.x.x.x closed by remote host.
Connection to x.x.x.x closed.
Transferred: sent 2156, received 1788 bytes, in 0.0 seconds
Bytes per second: sent 62256.4, received 51630.0
debug1: Exit status -1 

So, what had happened?

Apart from ‘fixing’ the firewall rules, I had also given myself extra group permissions, and in this case – ‘Apache’. The Apache group seemed to make sense so I could eliminate that extra step of copying, however, in doing so, this is where my problem was.

The Apache account is not allowed to log in, and so my actual login account was inheriting that account’s credentials, and thus, being booted out immediately.

Anyway, I thought I’d let you know.

Adding more permissions don’t always give you more access.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s