SSH client for AmigaOS with builtin terminal emulation

Hi again Salas00,

I'm sorry, I just don't know what to tell you about the types of
authentication being used...

I barely figured out how to get it working with ssolie's OpenSSH
(the docs are fairly incomplete/innacurate), but it's since been
working on all my Amigas and even from my Mac with the "id_rsa"
file copied over to it.

So I just don't what else to tell you about the technical details.

OK, I've noticed a few other things running SSHTerm on my Amigas...

First, I have encountered this problem sporadically and I haven't
been able to trace back what sets it off..

If I select text in the SSHTerm window (in an Alpine session) and
paste it into Notepad, I am seeing that most of the spaces (after
the first one) are getting stripped out of the resulting text.

Next, if I correct the missing spaces in Notepad, go back into
SSHTerm (and Alpine) and paste the text back in, then I'm seeing
the LF's or CR's (I don't remember which we use) get stripped out
in the resulting text.

Hope this helps.

Thanks again,

PJS

@salas00
Quote:

Check this out what i mean (start from 0:20 till end):

https://youtu.be/sa0VOzl_MCA

See, firstly it fast. Then, when there more things on screen it start to be slower and slower. Then at end of video i hit "enter" lot of time, and can be seen when almost all disappear in scrollbuffer it start to be again faster.

And the bigger i resize window, the slower things start to redraw.

Also, i can see that when this "slow" things happens, cpu hit 100%. Happens as far as i can see when things go to scrollbuffer.

EDIT: oh, even moving just a scrollbar of shell when there is some content in buffer make those slowdowns and 100% cpu loading hit! I.e. after making a video i just grab scrollbar and start to move it up-down more or less fast.

Maybe on tabor you use that "dma-based" onboard gfx driver which deal with?

@salass00

Very nice and stable release - and even irssi is working fine! Scandinavian characters seems to be displaying wrong ("?[K" instead of "ä" and "ö"), but I suppose this falls under full unicode support to be implemented in future.

Good work - small donation done!

Thanks a lot!!!!

Thanks a lot for your heroic achievement salas00.
You deserve a big donation.
I hope we all can help and gather some funds.

@salass00

Nice work. Donation just sent.

Version 1.2 of SSHTerm is now available:

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

@salas00
Tested!

In v1.2 speed of rendering now _MUCH_ faster! Thanks! The way to make it slower now is only to resize a window to be bigger. I.e. the bigger the window, the more CPU-loading happens when I do "ls -la" in a big directory.

If I set a window, for example, be 1920x1080, then when I do ls -la CPU loading happens to be at 100% and while listing happens, the mouse starts to be jerky (like it takes up all resources).

But if I resize a window to something like 1200x760, then already all fine. Cpu loading does not hit more than 80% when "ls -la" on big dir happens, it happens fast enough. Mouse through a bit "busy", but can be moved.

With a smaller size like 960x600, things is absolutely ok and fast (through mouse can be a little be busy in movement too), and only way to hit 95% of CPU loading is "ls -la /tmp; ls -la /tmp; ls -la /some_dir_with_lot_of_files;", etc. I.e. making listing be long enough.

But I compare with our pure shell, and when I do the same lots of "ls -la work; ls -la work; ls -la work" from sh, then it also takes up a lot of CPU power (through mouse movement always fluid anyway). And, seems that does not matter if I made OS's shell window be bigger or smaller, it always the same.

But it's understandable that SSHTerm does a lot more than just pure OS4s shell (network, ssh2 protocol itself, libtsm), so comparing, of course, can't be fair.

In other words, everything really good :) Maybe if a mouse can survive from slower movement when heavy listing/rendering happens, but that also not that important.

Very good work as usual from you, donation on the way!

EDIT: it seems mouse movement interruptions not related to the 100% cpu loading, but to the rendering itself. I.e. if you render anything , like run "make" , and it doing things, with compiling big files (so not fast rendering) and cpu loading just 20% , mouse start to move slower anyway.

So if for example you run "make" in sshterm, iconify it, and continue your work on workbench, then you will have mouse-movement interruptions everywhere once anything new will happens in sshterm.


EDIT2: Omg, even VIM works fine! With all the keys like "tabs", with all coliring and so on. What mean terminal support is very matured! Its almost putty! :)

@Salas00

Going heavy, and checked some terminal based demos, and they works!

Check this video: https://youtu.be/WlmMo_2ch6k

At begining i show how now scrolling + "ls -la" output works (all fine now), and then started from 1:00 run some terminal demos:

1). MANDELBROT (written using integer maths and 16-colors by Charles Cooke)

2). simulator of Langton's Ant (also by Charles Cooke)

3). NCMATRIX (a modified version of the Matrix screen saver by Chris Allegretta)

4). cacafire (one of libcaca's demonstration application)


All works ! Through, last one (and all ones which use "libcaca" for terminal based demos/apps), after running block all the keyboard input so i can't press "esc", or "ctrl+c", or anything, can't close even sshterm. While in original shell can do that of course.

@salass00

Wow! I love SSHTerm!




Would it be possible to have the hostname/IP and the user name in the title bar so when we have multiple windows opened one can spot the correct window to use?

How can I support your work on this?
Is that correct if I donate using the PayPal button at http://www.a500.org/ ?

@virgola

Quote:

Yes, that should work.

@densho

Quote:

That is pretty odd, as they work fine here on all the OS installations I've tested with (4.1 update 6, 4.1 FE update 1 and 4.1 beta).

What language and charset have you set in Locale prefs? I have English and ISO-8859-15.

Also what version of newlib.library do you have?

@salass00

Donated!
Great work!

@salass00

Sorry for late reply; I have same settings as you and newlib.library 53.36

Scandinavian characters display ok on remote shell, so it seems this is more related to Irssi after all... but, it is working just fine on windows Putty with same charset :)

One extra problem too: once you enter scandinavian characters to remote shell, you can delete them with backspace the double amount.

@densho

åäö is displaying fine for me in irrsi.

Just tried SSHTerm 1.2 to connect to my vmware ESXI 5.1.0 via ssh and it freezes/crashes.
Using OpenSSH/bin/ssh (os4depot) commandline works fine (it seems to use "old" AmiSSL v3).

Just cloned your sshterm git and compiled on my amiga, and here is part of the GR/crashlog:
Crash log for task "SSHTerm.debug"
Generated by GrimReaper 53.19
Crash occured in module newlib.library.kmod at address 0x01B13894
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
0: 6FFAE000 5946DF20 00000000 00000000 00000000 00000010 00000000 00000001
8: 59555338 00000000 59394018 01B13844 00000000 5FDD9EFC 6FF18B50 00000003
16: 5C1F2BE0 59555338 00000001 0000000C 7F587E9C 5EDAC852 59544464 5954236C
24: 00000004 59544928 59544574 5E500D32 595444BC 59543D68 00000000 59552678


FPR (Floating Point Registers, NaN = Not a Number):
0: nan nan 0.45455 0.181836
4: 0.222222 4.5036e+15 4.5036e+15 4.5036e+15
8: 379 1334 4.5036e+15 256
12: 4.5036e+15 172544 -2.34186e+06 -4.93319e+304
16: 3.11296e+284 -3.80848e-05 6.43513e-169 6.21281e-82
20: 9.82126e-10 3.83483e-91 -3.42755e+229 -1.0871e-81
24: 1.11475e-23 1.16497e-50 -2.81214e-07 -2.07549e+294
28: 1.53473e-126 0.00223912 -5.238e-10 3.89869e-164

FPSCR (Floating Point Status and Control Register): 0x82004000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x0002F030
Condition (cr) : 0x5937D5F4
Instruction Pointer (ip) : 0x01B13894
Xtended Exception (xer) : 0x58DCE018
Count (ctr) : 0x6FF714D0
Link (lr) : 0x7FC43920
DSI Status (dsisr) : 0x58DCDDD0
Data Address (dar) : 0x01A83048



680x0 emulated registers:
DATA: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 6FFB8000 A2978600 00000000 00000000 00000000 00000000 00000000 5946CAD0
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0x01B13894 belongs to module "newlib.library.kmod" (HUNK/Kickstart)

Stack trace:
native kernel module newlib.library.kmod+0x00003874
[src/malloc.c:104] SSHTerm.debug:strdup()+0x1c (section 1 @ 0x6E94)
[src/userauth.c:1967] SSHTerm.debug:libssh2_userauth_keyboard_interactive_ex()+0x5e0 (section 1 @ 0x258DC)
[src/main.c:311] SSHTerm.debug:sshterm()+0x800 (section 1 @ 0x19C8)
[src/start.c:269] SSHTerm.debug:main()+0x774 (section 1 @ 0xCC8)
native kernel module newlib.library.kmod+0x000020ac
native kernel module newlib.library.kmod+0x00002d14
native kernel module newlib.library.kmod+0x00002ef0
SSHTerm.debug:_start()+0x1e0 (section 1 @ 0x1DC)
native kernel module dos.library.kmod+0x000255c8
native kernel module kernel+0x0003bc38
native kernel module kernel+0x0003bc80

PPC disassembly:
01b1388c: 38a00010 li r5,16
01b13890: 7ca103a6 mtxer r5
*01b13894: 7cc3642a lswx r6,r3,r12
01b13898: 7ccb389d .word 0x7CCB389D
01b1389c: 7d8c5a14 add r12,r12,r11

System information:

CPU
Model: AMCC PPC460EX V1.2
CPU speed: 1155 MHz
FSB speed: 231 MHz
Extensions:
...


Using ssh openssl commandline:

@jabirulo

At the moment keyboard interactive authentication will only work when the password is specified on the command-line.

It is due to a mistake I made when adapting the code from ssh2-handler to SSHTerm and should be fixed in the next release.

@salass00

ok, didn't try that, thx. Will try it ASAP

Version 1.3 is now available:

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

@salass00

The same commandiline:
sshterm 192.168.1.199 user=root <password>

in v1.3 just opens windows with black background and nothing happens,
and if I don't set password it doesn't request for password.

v1.2 requested for password, although it wasn't working, but as you post adding to commandline <password> works fine.