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 firstname.lastname@example.org 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.