Posts Tagged ‘ssh’

sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation

Tuesday, June 1st, 2021

This is a problem which bugs the Internet. Many solutions were suggested. All of them work sometimes (like making sure that the permissions on the private/public SSH key files are correct).

One solution which never gets mentioned is about DNS. When attempting login to a remote server, the server attempts to resolve the connecting address (yours) using the DNS server defined to the server. This is the default for SSHD, and I seldom see any reason to change it. However, if the DNS servers are inaccessible, then the login takes very long (actually – waiting for the DNS query attempt to timeout). If this thing happens when using SSH-agent (I use KeePass2 with KeeAgent, as a very secure means of protecting my private keys. I suggest you check it out), the timeout might be just long enough to timeout on the agent’s side, and thus, produce the dreaded ‘sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation’ error message.

The easy two possible solutions (pick one)L

  • Disable SSH DNS query (Remove the comment before ‘UseDNS no’ directive in /etc/ssh/sshd_config)
  • Disable DNS servers – comment out the defined servers in /etc/resolv.conf

This solves the timeout, and with it – this message, and your connection problems.

Using yum with SOCKS proxy

Sunday, June 30th, 2019

SSH is a wonderful tool. One of its best features is the ability to pierce a firewall and let you go through it. If you’re using the dynamic port (-D as argument in command line openSSH), you actually get a SOCKS5 proxy over which you can transport all your desired data.

This allows you the freedom of accessing the Internet from a restricted machine, on the condition it can connect via SSH to another unrestricted machine. So – how does it work?

To simplify things – you will need two sessions on your restricted machine. Use the first to connect via SSH to an unrestricted machine, with the argument, in our example, -D 10000

What it tells the SSH connection is to create a SOCKS5 proxy locally (on the restricted machine) over port 10000, and all the transport sent there – to transfer through the remote (unrestricted) server.

Using the other session, we can implement local variable like this:

export http_proxy=socks5://localhost:10000

export https_proxy=socks5://localhost:10000

It sets a variable which yum (among many other programs) can read and use. Afterwards, using the same session, running ‘yum update‘ or ‘yum install package‘ will result in yum running through the proxy connection. Of course – the SSH session to the unrestricted server must be active at all times, or else yum command will fail.

NetApp internals – how to add SSH keys without C$ nor NFS shares

Thursday, April 3rd, 2014

This post will describe the process of placing SSH keys using the internal ‘systemshell’ command of NetApp. As always – when doing something which the vendor did not intend you to do, do it very carefully. This data was obtained from NetApp forums, and while I do not have the original post to link (I usually link to the original, as a courtesy to the original author), this is the content, as is.

First, set to advanced mode:
filer> priv set advanced

Then, unlock and set a password to diag account:
filer*> useradmin diaguser unlock
filer*> useradmin diaguser password

Start the systemshell, create the directory you need and put the pubkey generated in the authorized_keys file:
filer*> systemshell

login: diag
Password: the same you set in the previous step

filer% mkdir -p /mroot/etc/sshd/root/.ssh
filer% vi /mroot/etc/sshd/root/.ssh/authorized_keys
filer% sudo chown -R root:wheel /mroot/etc/sshd/root
filer% sudo chmod -R 0600 /mroot/etc/sshd/root

Last, exit systemshell, lock diag account and exit advanced mode:
filer% exit
filer*> useradmin diaguser lock
filer*> priv set admin

If you want to do it for any other user, just replace the word ‘root’ with the said user.

An additional note – I had to create a user to perform ‘df’ operations only. The purpose was to be able to obtain data using ‘ssh’ without disclosing the keys used for root SSH access, by having a very limited user, designed to do that.

So the commands to create such a user are as follows:

useradmin role add df -a cli-df*,login-ssh
useradmin group add df_users -r df
useradmin user add df -g df_users
(here you will be asked to enter the user’s password)

Hope it helps!



Service account

Wednesday, May 27th, 2009

Assume you have a single purpose account. Maybe some service account, user which should run a single task ever, or even a case of a limited menu interface. You want your user(s) to reach there using SSH because that is the method to do it right and secured. You want it to be easy for the users – combine your ability to have a secure session with ease of use through SSH keys, while fearing an abuse.

You can probably see how this balances. In most cases, it balances as “we will make our users’ life hard and they will have to type a password”, which is fine, except that you hardly ever actually enforce password policy or password age limitations, so you compromise security. Also – you have to trust your users to be nice, and never attempt to test the limits of your system. It’s bad, but finding a simple-to-manage solution for that specific single task you want is so complicated. You even consider (and sometimes actually enforce) chroot environment, which is such a pain to maintain. Either too secure or too loose.

Wow, that was long. The reason for this long prologue is that I have found a very nice utilization for a powerful and capable tool, jailkit, without the fuss of the entire chroot stuff. This is no invention of mine, but it appears to be a feature of this wonderful tool which is commonly ignored for no good reason.

This is the tool called jk_lsh – jailkit limited shell. You can define this tool on a per-user or per-group granularity through editing /etc/jailkit/jk_lsh.ini and changing the settings to match your requirements.

This allows you to use ssh keys for seamless authentication from defined client machines, and with limited set of commands which can be executed. Your job, as a sysadmin, is to make sure that these commands cannot be exploited – don’t let your users write permissions for these predefined commands so they would not be able to override your commands. Don’t let these commands reside on a share, so that replacing the command from another computer will not be possible, etc. Also – use full path for the child commands inside scripts, if used, so that altering PATH directives cannot change how your scripts work. This is quite basic, when you get to think about it.

The bottom line – your script on a remote machine which must run some specific task on this jk_lsh-modified machine can run safely and do only what it was intended to do. Same goes for icons on your users desktops, with a specific ssh command included.

I recommend this configuration – enjoy the benefits of controlled environment without the pain of chroot. That is – if it fits your needs, of course.

Minimal Centos5 and SSH Server with X forwarding

Friday, October 10th, 2008

Installation of minimal selection of Centos 5 – only base, core and dialup selections, will leave a small-sized system, with the minimum required.

This is a good setup to start setting up a firewall, and it lets you add any required package later using ‘yum’.

This said, you cannot forward X over SSH at this state. A minimal setup is a minimal setup, after all. I was searching for the package required to allow X forwarding over SSH, and found it – xorg-x11-xauth

Install this one, and X will be forwarded over your SSH connection (you still need to connect with the ‘-X’ flag from the client).