Git: Agent admitted failure to sign using the key

Just as an internal note, if you get the following error trying to pull or push to a git repo:

“Agent admitted failure to sign using the key”

Your issue might be due to simply not having an identity defined in SSH. Simply use the “ssh-add” command to fix it.

Tunel SSH revertido

Si tienes la suerte de tener un servidor al cual te puedes conectar en SSH, y tienes que conectarte (en terminal, en SSH) a la compu de un amigo que está atrás de un router, este tutorial es para ti!

Un tunel SSH es un especie de “canal” virtual dentro del cual los datos pueden pasar de una compu a otra. Como SSH es un protocolo seguro, se asume que estos datos, pasando ahí, son tan seguros que SSH mismo.

Cuando una compu está a trás de un router, el problema es que uno puede acceder al router pero no a la compu misma. Se puede arreglar configurando un firewall con redirección de puertos en el router, pero ya es algo avanzado, y si no tienes la mano sobre el router y tu amigo no sabe como configurarlo… estás frito.

La solución entonces es:

1. que el amigo se conecte a tu servidor en SSH (le puedes habilitar una cuenta o dar tu cuenta con otra contraseña)
2. que te conectes también al mismo sevidor
3. en el servidor mismo, que te conectes al puerto en el cual tu amigo se conectó

Por ejemplo…

Tu amigo:

ssh -R 54321:localhost:22 usuariocompartido@138.47.99.99

Tu:

ssh usuariocompartido@138.47.99.99
ssh localhost -p 54321

Y ya está! Estas en el servidor de tu amigo, conectado en SSH!

Using SSH for tunneling, kicking users, etc

A very useful resource (in French) to use SSH, with specific use cases: http://pix-mania.dyndns.org/mediawiki/index.php/OpenSSH#Les_tunnels_SSH

Another useful (and short one for tunneling): http://www.howtoforge.com/reverse-ssh-tunneling

In short, if you have a configuration with 3 computers (A – B – C) and you want to connect to A from C but A doesn’t allow direct SSH connection, you can do the following:

1. On A and B, install openssh-server
2. On A, open an SSH connection to B: ssh -R 5000:localhost:22 user-on-B@B
3. From C, connect to B: ssh user-on-B@B
4. Using the open connection on B, open a connection to A: ssh -p 5000 user_on_A@localhost

This should get you all ready to work on A.

Another special case is you have A-B-C, you are on C and want to access the internal website running on A, but you can only access B in SSH, and from B, access A.

1. Install openssh-server on A and B
2. From C, instruct your SSH client to connect to B and to link your local port 8080 to A’s port 80: ssh -L 8080:A.A.A.A:80 user_on_B@B.B.B.B
3. Open your browser on http://localhost:8080

Easily avoid using your password in an SSH connexion: ssh-copy-id

On Linux systems, there used to be a mildly complicated but tedious way to allow you to SSH another computer using your public key, which involved finding and copying your public key on the other host, then connecting to the host and putting this key into ~/.ssh/authorized_keys.

Now there is a much simpler way to do that… Just launch the following command (with your own data), enter your password, and that’s it!

ssh-copy-id  yourusername@remote.host.address

I love administrative simplification!

Why using root on UNIX/Linux is bad ?

A lot of people use the root account to do anything they need, just because it is easier…

This is a really bad idea, as that user can do anything to the system. Not only can he access/delete/modify any file and its permissions, but he can mount/unmount filesystems, kill/start/stop processes, add hardware to the machine, stop the machine, create/delete semaphores/pipes, … and all that even wiping out any evidence of the modifications applied.

Annoyingly, there is no real practical way of disabling the root user on a Unix system.

All that can, of course, be done even without the actual user knowing or willing it (a virus or another harmful script/program executed by root could do anything it wants).

Many times, people use the root account to compile programs. The problem is that most of the time, they don’t even check the makefiles, which could be really harmful. They should instead compile everything with another user, and only change to root to do the final make install.

An even worst idea is to allow remote or graphical connections using it. If someone (or something, like a virus) directly logged remotely as root, there isn’t any way to know who it was in fact. Forcing the logging as another user instead, and changing to root afterwards at least ensures the bad guy has to crack at least two accounts (root and a user). Moreover, when you know that the user account has been compromised, you can disable it, not root.

The problem is often just that the user has already done a lot of things as root and it would represent a lot of work to revert the rights and permissions on files to a regular user and/or test if everything works as user. It is a never-ending loop. We highly recommend you do not try to go further in that direction. Take the time to fix all this, your system will become much safer.

It might seem easier not to manipulate the permissions to exactly match what you need, especially when several people need to read and modify them. But in the long run, this is clearly not a solution.

sudo might be a practical solution to the problem.

This article was first written in October 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/86)

SSH

SSH (the Secure SHell) is a secure replacement for many UNIX tools like telnet, ftp, rsh, rcp, rlogin, rexec, and many more, which have proven to be insecure, even if most UNIX systems still use them by default, and even Microsoft has now begun to integrate those into his operating systems.

I’ll talk about the most used one, and free OpenSSH, which has been created by the OpenBSD team. OpenSSH implements both sides of the communication: client and server.

« OpenSSH is a FREE version of the SSH protocol suite of network connectivity tools that increasing numbers of people on the Internet are coming to rely on. Many users of telnet, rlogin, ftp, and other such programs might not realize that their password is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. Additionally, OpenSSH provides a myriad of secure tunneling capabilities, as well as a variety of authentication methods. »

This article was first written in July 2003 for
the BeezNest technical website (http://glasnost.beeznest.org/articles/41)

HOWTO Autocomplete hostnames with bash while using SSH

This article was first written in October 2007 for the BeezNest 
technical website (http://glasnost.beeznest.org/articles/364).

On most GNU/Linux distributions, bash is able to read hostnames in  /.ssh/known_hosts to autocomplete ssh commands. For security reasons though, hostnames are no longer stored in clear text in those files on most distributions, defeating this feature of bash’s autocompletion.

To tell SSH (client) to not obfuscate hostname, just set the HashKnownHosts option to no in /etc/ssh/ssh_config.