Posts Tagged ‘authentication’

The StartTLS replacement for the old telnet to SMTP server on port 25

Friday, February 23rd, 2018

When you need to troubleshoot SMTP issues, it is a known fact that a simple telnet to port 25 of the SMTP server in question would get you far. It will get you to see the problems.

When connecting to Office365 ( to relay mail, and you want to check how things work, you can use openssl to wrap in StartTLS your old telnet connection by running this:

openssl s_client -starttls smtp -crlf -connect

From there, you can run your plain old “ehlo user” and all these commands like you are used to.

Just a small note about authentication: if you are facing SMTP which requires authentication, there are few methods you can use. Let’s assume your user is ‘[email protected]’ and your password is ‘password’.

If you are allowed to use the PLAIN method, you need to generate the login/password string into base64, like this:

perl -MMIME::Base64 -e ‘print encode_base64(“\000user\\000password”)’

You could use shell with base64 command to perform the convertion:

echo -ne ‘\[email protected]\0password’ | base64

The result would be a string similar in shape to this: AHVzZXJAZG9tYWluLmNvbQBwYXNzd29yZA==

Then enter the SMTP server at the right prompt:


If you are allowed to use the LOGIN method, you need to generate base64 string for your user and your password separately, like this:

perl -MMIME::Base64 -e ‘print encode_base64(“user\”)’


echo -ne ‘[email protected]’ | base64

The result is dXNlckBkb21haW4uY29t

Same goes for the password field. Choose which of the next two lines you wish to use:

perl -MMIME::Base64 -e ‘print encode_base64(“password”)’

echo -ne ‘password’ | base64

The result is cGFzc3dvcmQ=

Now, for the prompt, we will run:


We’ll get the base64 query for username, so we just type/paste the user base64, and press on Enter. Then we’ll get the base64 prompt for password, so we will type/paste the password base64, and press Enter.

That’s all.

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.