Access server

›››››››››››››› SSH

SSH keys provide a more secure way of logging into a virtual private server with SSH than using a password alone. While a password can eventually be cracked with a brute force attack, SSH keys are nearly impossible to decipher by brute force alone. Generating a key pair provides you with two long string of characters: a public and a private key. You can place the public key on any server, and then unlock it by connecting to it with a client that already has the private key. When the two match up, the system unlocks without the need for a password. You can increase security even more by protecting the private key with a passphrase.

›››››››››››››› Making changes in ssh

Remember to:

 sudo service ssh restart

Tip: I can check all available services in /etc/init.d

Attention: if there are problems, grep to see if it actually stops the service Like this:

 sudo service ssh stop

 ps aux | grep ssh

 sudo service ssh start

 ps aux | grep ssh

›››››››››››››› Debug

Debug with a -v flag. max 3 "v"s

 ssh <user>@<server> -vvv 

›››››››››››››› Create RSA Key Pair

You create your RSA key pair in the computer from which you want to log to the server.

I can use this key pair for several servers, but if I want to enter a same server from different computers, I create different rsa key pairs.

Lo voy a crear a nivel local [en mi compu] y esa va a ser la llave rsa ssh que voy a usar para entrar en mis vps. NO genero una para cada vps sino que esa misma me sirve para todas. Si voy a usar varios ordenadores para entrar en un vps, sí necesitaré crear una llave ssh por máquina desde la cual estoy accediendo.

So each admin in a server is going to have at least one rsa key pair.

Be careful to pay attention from which user you create this in your local machine [computer]. Since the rsa key pairs are saved in a hidden directory in my user home directory [~/.ssh], if Im trying to login from a different user, it will confuse home directories since each user has a different home directory.

So, from the user in my localmachine that I wish to use to access the server, I will create my rsa key pair:

ssh-keygen -t rsa -b 4096

By default it will generate two keys in ~/.ssh, a public key and a private key. We are going to copy our public key to the server. If we don't have access to this server, we will send it to an admin of Anarcha server so that she can do it.

When generating the key, you will need to introduce a passphrase.

›››››››››››››› Copy public key to the server

After generating an SSH key pair, you will want to copy your public key to your new server.

To securely copy the public key, we shall enable password authentication on the remote server, by editing the /etc/ssh/sshd_config file, and disable it after having copied the public key

sudo nano /etc/ssh/sshd_config

uncomment and set PasswordAuthentication to yes and then to no after copying is done.

PasswordAuthentication yes

To copy your public key, run the following command

ssh-copy-id <user>@<server>

To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the .ssh directory in the user's home directory. Assuming that we are going to create superuser accounts for each new admin we will do the following:

›››››››››››››› Creating new sysadmin accounts

Changing to root user

sudo su

Check the sudo users

 grep '^sudo:.*$' /etc/group | cut -d: -f4

If you are not yet, we create a superuser [note: it will ask me to introduce a passwd]

adduser <superusername>

Then we will add the superuser to sudoers:

usermod -aG sudo <superuser>

We now change to superuser:

su <superuser>

When we change user, we will be by default in the user's home directory [~]. You can do cd ~ just in case.

It is also possible to create a user [waters for example] and give it a limited privilege [to execute a certain command[s] as root]. To do this, create a new file [waters for instance] in the /etc/sudoers.d/ directory

touch /etc/sudoers.d/waters

and edit it with visudo [this is very important as it alerts you regarding any syntax errors]

sudo visudo /etc/sudoers.d/waters

and add the following line to allow the user waters to use a chmod command for example

waters ALL=(ALL) /usr/bin/chmod

To allow user waters to run a chmod command without entering a password edit the file this way

waters ALL= NOPASSWD: /usr/bin/chmod

›››››››››››››› .ssh directory and authorized_keys

Creating .ssh directory and authorized_keys document in the superuser home directory.

As the superuser to whom we want to give ssh access to the server, create a new directory called .ssh and restrict its permissions with the following commands:

mkdir .ssh

chmod 700 .ssh

chown superuser:group

Now open a file in .ssh called authorized_keys with a text editor. We will use nano to edit the file:

nano .ssh/authorized_keys

Now copy-paste the public key [which should be in your clipboard] by pasting it into the editor. Save and close.

ctrl + s

ctrl + x

Now restrict the permissions of the authorized_keys file with this command:

chmod 600 .ssh/authorized_keys

chown superuser:group

Type this command once to return to the root user:

exit

As we are creating a new user + authentication as root, we have to change the owner of the .ssh directory to the new user [recursively - R]

chown <user>:<user> .ssh -R

Now you [the new sysadmin] may SSH login as your new user, using the private key as authentication.

. . . . . . › After reboot

Access physical mainframe to reboot the encrypted virtual machine. Ask permissions to the syteradmins, by posting on the mailingslist anarchaserver@lists.systerserver.net

. . . . . . › SSH Reverse DNS Lookup Disable

The invalid logins are normal, since there are bots that try to bruteforce servers.

As for the "possible break-in attempt" message, The system is trying to do a reverse DNS lookup to match the connecting IP with the hostname that is trying to connect and fails to do so.

The setting that controls that is UseDNS in /etc/ssh/sshd_config

sudo nano /etc/ssh/sshd_config

y agrega la línea:

UseDNS no

sudo service ssh restart

Force ssh login to server

sudo nano /etc/ssh/sshd_config

and change & uncomment:

ChallengeResponseAuthentication no

PasswordAuthentication no

UsePAM yes

sudo service ssh restart

. . . . . . › Change ssh port access

sudo nano /etc/ssh/sshd_config

The first option that you may want to change is the port that SSH runs on. Find the line that looks like this: Port 22

If we change this number to something in between 1025 and 65536, the SSH service on our server will look for connections on a different port. This is sometimes helpful because unauthorized users sometimes try to break into servers by attacking SSH. If you change the location, they will need to complete the extra step of sniffing it out.

If you change this value, you will need to keep in mind that your server is running on the new port.

service ssh restart

So now you would have to access to the server like this:

ssh <superuser>@<server> -p <portnumber>

›››››››››››››› References

_ Thread: log full of "POSSIBLE BREAK-IN ATTEMPT!"

_ How to start, restart and stop SSH service

_ How to add SSH key to server

_ How to add user to sudoers with best practices & examples

_ How to run sudo command without a password on a Linux or Unix

›››››››››››››› Interview Meltionary Access Server

This conversation took place between Anarchaserver, Lever Burns, Systerserver and the arts-design duo MELT on the 4th of February 2022. It has been shortened and edited for clarity by MELT. Present were: Estragon, Mika, ooooo, spideralex, nate, Mara, Ren Loren and Isabel.

Anarchaserver, Lever Burns and Systerserver are a distributed group of people based in Belium, the Netherlands, Greece, Spain and Italy, working on feminist infrastructures and servers. Their work on setting up a peertube instance to provide an online video based residency to artists, is currently supported by the program A Fair New Idea?! (AFNI).

MELT is an arts-design duo currently working on an email server called ACCESS SERVER that anonymizes, collects and financially compensates access requests that disabled people send to institutions. ACCESS SERVER is currently supported by a fellowship with the Het Nieuwe Instituut.

The feminist servers invited MELT for a one month residency in order to try out feminist infrastructures for their project. We decided to begin the residency with an interview, focusing on how we have shared language in our projects but the ways they make meaning, are different. MELT found the subpage ACCESS SERVER on the website of Anarchaserver – a subpage set up to help people to access this feminist server. MELT wanted to ask about and consider the resonances between ACCESS SERVER as a way of logging into the feminist servers' infrastructure, and ACCESS SERVER as a way of making access for disabled people into cultural institutions. What followed was a conversation around technology, trans*feminism, sysadmin work, access, and disability.

We met in a hybrid way: some of us were present at Varia in Rotterdam and enjoyed coffee and fruits together, some joined via the self-hosted Jitsi instance of futuretic, an alied autonomous server.

Interview Meltionary