Posts Tagged ‘ssh’

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).

Solaris SSH weird behaviour

Thursday, July 3rd, 2008

Sun likes IPv6. They like it so badly that they strive to use it in all cases.

Solaris 9 and 10 SSH daemon is bounded to IPv6, which leads to a problem when trying to forward X. Editing the config file /etc/ssh/sshd_conf and assigning the SSH daemon to IPv4 address (bind to address 0.0.0.0) is not enough. You need to make sure that the sshd process is started with the “-4” flag. In Solaris 10, it means editing /lib/svc/method/sshd and appending “-4” to the sshd start command.

I wonder what will happen after an upgrade or a patch…