SSH client for AmigaOS with builtin terminal emulation

@salass00

Quote:

Turns out that I was doing this wrong.

Instead of doing:

ULONG isfixed;

IDiskfont->EObtainInfo(olf->olf_EEngine, OT_IsFixed, &isfixed, TAG_END);

I should be doing:

isfixed = IUtility->GetTagData(OT_IsFixed, FALSE, olf->olf_OTagList);

@salass00

Keep up the great work Fredrik! Looking forward to your
work on the SSH client. Sent some paper thanks.

I was wondering about the terminal emulation aspect of
your client... Are doing your own implementation of ANSI,
VT codes or how is that going to work?

I've been using the console with SSH on a shell account for
years, but it's always been a challenge. Hard to set up.
Hard to get the server talking with the Amiga. Hard to
keep working (apps no longer seem to pay attention to
TermCap, etc., like Alpine).

Very curious to hear what your plans are and how things are
going!

THANKS again,

PJS

@pjs

Thanks for the donation!

Quote:

Right now I'm using libtmt which provides a pretty basic ansi terminal emulation. Later I might look into using libtsm which is similar and has more features, but is also more complex.

Basically libtsm provides the terminal emulation so I feed it whatever data comes from the ssh channel and it handles it appropriately.

What libtsm doesn't do is anything platform specific like opening a window, drawing text or handling input from the user. To do rendering libtsm lets you provide a callback function which is called when the display needs to be updated, like if there is new text or the text cursor has been moved.

The input handling I do right now using IDCMP_RAWKEY and IKeyMap->MapRawKey(), but I think I might change this as MapRawKey() converts some special keys (cursor keys, page up/down, home/end, etc.) into amiga style CSI codes which are not completely ansi compatible. I have some code in place to convert them into ansi but I think it would be easier for me to convert these keys directly from the raw key codes.

@salass00

Cant wait to try out your SSH client. Donation send!

@Skateman

Thanks for the donation!

@salass00

Any update you want to share? I check every day :)

Cheers,
Bill "tekmage" Borsari

@tekmage

Not much visible progress in the program.

I did add code for a password requester which I had left out before and actually forgotten that I did that because I use ssh-agent/ssh-add when testing so I don't have to type in my passphrase every time.

I also rewrote the entire terminal emulation part of the code using libtsm and made it into a private BOOPSI gadget class.

A couple of things that I intend to work on next:

- Rewrite keyboard input handling and let termgclass and libtsm handle most of the work. I was going to use tsm_vte_handle_keyboard() but it seems to expect X11 codes, so it is probably simpler and more efficient to write a similar function that handles AmigaOS raw key codes directly.

- Move init and cleanup of ssh session into helper functions making it easier to change and extend the program in the future. In order to achieve this all the ssh session data need to be stored in a struct rather than being spread out in a bunch of local variables as they are now.

The rewrite of the keyboard input handling is done now, and it's using the new tsm_vte_handle_keyboard_amiga() function.

Not all of the special keys are implemented but of some that are they are working much better now (i.e. correctly).

A new problem that I have yet to get to the bottom of though, is that every time I type a letter the cursor moves to the start of the command line prompt which means that if I write "exit" it comes out as "tixe" instead.

Edit: The problem was because I was lazily assuming that the output data would always be NUL-terminated as with libtmt. With single characters it isn't so a stray '\x01' character was always sent as well.

Sweet!

Marking text with mouse and copy to clipboard with RAMIGA+C (or Edit->Copy from menu) is now supported and paste operation is currently being worked on.

Initially marking text was extremely slow due to the libtsm functions involved forcing an update of the entire terminal display, but after rewriting the aging code so that it only updates the cells that have changed it is very fast and uses very little CPU.

Menus are also now implemented, as is iconification for the terminal window (very easy to do now that I'm using window.class).

@salass00

How do you plan to release it?

Is it in a future OS4 update, enhancer, a free download from somewhere or as a paid download or maybe something else?

@smf

I haven't decided yet.

While the idea of releasing a program on AmiStore for a small fee does have some appeal to me, not least because I could use the money, it might be too much of a niche product for that to be worth it though.

I had to make some small extensions to the libtsm API, but it is now possible to attach a scroller to the termgclass terminal display and use it to scroll within the libtsm scrollback buffer.

It is a little slow on my Sam460 at the moment given that it's redrawing every cell of the terminal display, but I'm hoping that I can make the incremental scrolling faster by using ScrollRasterBF() and only redrawing the new lines and any damaged window regions that are exposed by the operation (if the window is partially covered up by another one).

Scrolling now uses a separate refresh type, which uses ScrollRasterBF(), and is much faster because of it, and really responsive on the Sam460 I use for testing.

BTW, assuming that you have a new enough z.library (V53.5) and AmiSSL (V4.3) installed it even works under 4.1 update #6 (I just tested it).

Resizing of the terminal window is now mostly supported. What is missing still is code to request a new size from the remote host.

In implementing this I ran into a few problems that should be fixed now.

First off GM_LAYOUT which notifies the termgclass that it now has a new size is called from the context of input.device even if LAYOUT_DeferLayout is TRUE. This caused problems with the newlib memory allocation routines because they rely on the pr_CLibData field which does not exist for a task. After trying a few different workarounds the easiest solution I found was to just use a custom memory allocator, which for now is based on dlmalloc (same as newlib.library one) but a little simpler.

One of the other solutions I tried was to use clib2-ts, but clib2's UTF-8 support is too lacking and it made the executable a lot bigger, so I scrapped that idea.

The other problems were cosmetic in that libtsm would add empty lines when the window was made bigger, when it could have simply moved in lines from the scrollback buffer, and also when the window was made smaller these empty lines would not get removed resulting in unnecessary scrolling.

I've fixed those problems as well now, however it took a very long time as I made quite a few mistakes along the way and every time it would crash it would hard lock the computer without producing any useful GR or stack trace because the crashes were in GM_LAYOUT on input.device context.

Version 1.1 of SSHTerm is now available at github:

https://github.com/salass00/sshterm/releases

@salas00
Tried !

Installed on my linux openssh server, and trying from amigaos4 firstly like this:

ram:> SSHTerm 192.168.1.102 22 kas1e

and instead of giving me prompt for password it just say "Authenticatoin failed".

So , then i tried to ommit "22" , just as:

ram:> SSHTerm 192.168.1.102 kas1e

and then it ask me for password, and i can login ! And it actually works :) Scrollbar works for sure , all coloring fine too. All works.

(open in new tab for fullszie)


Only what i noticed, when i do "ls -la" its not very fast. Pretty slowly refresh things.

Also doing "vim test.txt" while runs fine, it didn't clear buffer and i can see last output from "ls -la" right in the vim window. Just like swap of buffers happens, but last one keeps on screen.

Also i tried to login like this:

ram:> sshterm 192.168.1.102 22 kas1e mypassword

and i have "wrong number of arguments".

But damn, it works anyway ! First proper ssh term !!

Hi salas00 !

Congratulations on your release of SSHTerm! Fantastic and very much
appreciated.

I installed it and have been testing it with my shell account on
XMission. Normally, I log into that account using openssh on my
Amigas and have managed to force the server to use the console's
ANSI terminal support (most of the time).

Once I got a command line that worked, I was able to connect to
XMission and it seemed to work great. Even on my little ole SAM440
on wifi it didn't seem terribly slow or cause any CPU load.
Resizing a full shell window was the only time things crawled (maybe
it shouldn't try to do constant redraw?).

I also found that your terminal emulation was working well! :D
I've been finding more and more shell apps that simply ignore the
TERM settings which just kill Amiga ANSI use.

But I had a few challenges with getting SSHTerm to connect to start
with...

First, it doesn't work with openssh and its keyfile. As per the
openssh docs, my "id_rsa" is in DEVS:ssh/. Any of these command
lines with SSHTerm never worked:

------

SSHTerm/SSHTerm shell.xmission.com <un> devs:ssh/id_rsa.pub
<< window open/closed >>
Authentication failed

SSHTerm/SSHTerm shell.xmission.com <un> devs:ssh/id_rsa
<< window open/closed >>
Authentication failed

SSHTerm/SSHTerm shell.xmission.com USER <un> KEYFILE devs:ssh/id_rsa
<< window open/asked me for pw/closed >>
Authentication failed

SSHTerm/SSHTerm shell.xmission.com PORT 443 USER <un> KEYFILE devs:ssh/id_rsa
<< window open/asked me for pw/closed >>
Authentication failed

SSHTerm/SSHTerm shell.xmission.com USER <un> PASSWORD <ssh pw> KEYFILE devs:ssh/id_rsa
<< window open/closed >>
Authentication failed

SSHTerm/SSHTerm shell.xmission.com PORT 443 USER <un> PASSWORD <ssh pw> KEYFILE devs:ssh/id_rsa
<< window open/closed >>
Authentication failed

SSHTerm/SSHTerm shell.xmission.com PORT 443 USER <un> PASSWORD <ssh pw>
<< window open/closed >>
Authentication failed
------

Finally, I gave up on trying to use my SSH keyfile and I tried
connecting with the shell account's "normal" password...

------

SSHTerm/SSHTerm shell.xmission.com PORT 443 USER <un>
<< asked me for my shell pw and IT WORKED!! :D >>

SSHTerm/SSHTerm shell.xmission.com 443 <un>
<< window open/closed >>
Authentication failed

SSHTerm shell.xmission.com PORT 443 USER <un> PASSWORD <shell acct pw>
<< IT WORKED >>

SSHTerm shell.xmission.com PORT 443 <un> <shell acct pw>
<< IT WORKED >>

SSHTerm shell.xmission.com 443 <un> <shell acct pw>
wrong number of arguments

SSHTerm shell.xmission.com <un> <shell acct pw>
<< IT WORKED >>

------

So it seems like SSHTerm is also having problems parsing the command line
for arguments... Even if the exact same combination of arguments fails
if you don't have the keywords (PORT, USER, etc). It seems to really need
the "PORT" in there if you're going to set a port number.

Finally, wishes... I hope you might consider an option for letting the user
set the window initial size, colors, sound.

In any case, Thanks again! It's a wonderful achievement. I'll start
using it on all my machines and see how it gets along.

THANKS!

PJS

@kas1e & pjs

The PORT, KEYFILE and MAXSB all need to have the keyword specified to work (that's what the /K in the AmigaDOS command template means).

The PORT argument only needs to be specified if the ssh port is changed from the default 22.

@kas1e

Quote:

Running "ls -la" in either ~ or /bin (both have quite a large amount of files in them) is near instantaneous on my Tabor machine (I don't have my Sam460 connected so can't test there ATM).

@pjs

Quote:

Does the ssh server allow other authentication types? If so SSHTerm will use them first instead of public key authentication.

In ssh2-handler I made the KEYFILE option force use of public key method if it is supported by the server, but this code doesn't seem to have made it into SSHTerm for some reason.

I have my ssh servers set to only allow public key authentication as this method is more secure than the other ones.