From: Tony Nelson on 22 Mar 2010 16:00 On 10-03-22 15:33:20, Dotan Cohen wrote: > On 22 March 2010 18:46, Tony Nelson <tonynelson(a)georgeanelson.com> > wrote: ... > > p.s. I hate screen. > > > > Why? I actually like it. Besides having to learn a new set of odd keybindings, I use the scrollback of a terminal a lot, and entering a mode to do it was not satisfactory at all. Even a standard Linux VT worked more easily. I wanted to like screen, as it's ability to hold a session open after losing a connection would be useful to me. -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson(a)georgeanelson.com> ' <http://www.georgeanelson.com/> -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/1269287839.6368.2(a)localhost.localdomain
From: Johann Spies on 23 Mar 2010 03:40 On Mon, Mar 22, 2010 at 12:52:36AM +0200, Dotan Cohen wrote: > I am managing a small embedded device that I SSH into over the LAN. To > run commands, I use KDE Konsole, and to transfer files I use Konqueror > and SFTP. I understand that SFTP also runs over SSH, so is there a way > to send files in Konsole as well? I am familiar with the FTP commands > such as cd, lcd, put, and get. Are there equivalent commands for SSH > terminal connections? Several ways: * You can use scp both ways as others have said. * Use rsync over ssh: rsync -e ssh -av <user>@remote:directory/files . * Use lftp fish://<user>@remote and then you can put,mput, get,mget and much more * Do the same with gftp (using an ssh/fish-connection) * Use filezilla like gftp Regards Johann -- Johann Spies Telefoon: 021-808 4599 Informasietegnologie, Universiteit van Stellenbosch "Jesus said unto her, I am the resurrection, and the life: he that believeth in me, though he were dead, yet shall he live: And whosoever liveth and believeth in me shall never die. Believest thou this?" John 11:25,26 -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100323073726.GG11072(a)sun.ac.za
From: Tzafrir Cohen on 1 Apr 2010 09:20 On Mon, Mar 22, 2010 at 01:02:10AM +0200, Dotan Cohen wrote: > On 22 March 2010 00:57, Selçuk Mıynat <selcukmiynat(a)gmail.com> wrote: > > On Mon, Mar 22, 2010 at 00:52, Dotan Cohen <dotancohen(a)gmail.com> wrote: > >> I am managing a small embedded device that I SSH into over the LAN. To > >> run commands, I use KDE Konsole, and to transfer files I use Konqueror > >> and SFTP. I understand that SFTP also runs over SSH, so is there a way > >> to send files in Konsole as well? I am familiar with the FTP commands > >> such as cd, lcd, put, and get. Are there equivalent commands for SSH > >> terminal connections? > > > > Are you looking for scp? > > > > http://en.wikipedia.org/wiki/Secure_copy > > http://www.helpdesk.umd.edu/documents/4/4801/ > > > > No, scp is for sending files to a remote machine that the user has yet > to connect to: > localhost$ scp /path/to/file.txt user(a)remoteMachine /remote/path/ (wrong syntax: scp /path/to/file.txt user(a)remoteMachine:/remote/path/ ) While this is not what you asked for, I still prefer scp. scp can be made much more convinient to use, once you allow tab completion of remote file names. scp file.txt user(a)remoteMachine:/rem<tab> This works if you cna login without a password to user(a)remoteMachine . There are several ways to do that: 1. Passphrase-less key 2. key + ssh-agent I suppose people in this list are familiar with the above two. The down-sides with those two are: 1. They still require estabilishng an extra SSH connection per pressing of <tab>. 2. They may require extra setup on remoteMachine. Luckily openssh provides a better alternative. In my .ssh/config I have: Host * ControlMaster = auto ControlPath = ~/.ssh/socket/control_%h__%p__%r__%l This means that whenever I connect to a new host, ssh creates a socket that allows multiplexing new ssh connections on the already-established SSH connection. After-all the SSH protocol was designed to support multiple streams (for e.g. port forwarding). With this set, scp works nice and fast to a remote host. BTW: it seems that in squeeze rsync now has the same sort of completion. As usual, I rely on the shell's history to provide me some sort of context. I usually also copy pathes from a remote shell window on the target system. -- Tzafrir Cohen | tzafrir(a)jabber.org | VIM is http://tzafrir.org.il | | a Mutt's tzafrir(a)cohens.org.il | | best ICQ# 16849754 | | friend -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/20100401131417.GS16560(a)pear.tzafrir.org.il
From: Sjoerd Hardeman on 1 Apr 2010 09:50
Tzafrir Cohen schreef: > While this is not what you asked for, I still prefer scp. > scp can be made much more convinient to use, once you allow tab > completion of remote file names. > > scp file.txt user(a)remoteMachine:/rem<tab> > > This works if you cna login without a password to user(a)remoteMachine . > There are several ways to do that: > > 1. Passphrase-less key > 2. key + ssh-agent > > I suppose people in this list are familiar with the above two. The > down-sides with those two are: > > 1. They still require estabilishng an extra SSH connection per pressing > of <tab>. > 2. They may require extra setup on remoteMachine. > > Luckily openssh provides a better alternative. In my .ssh/config I have: > > Host * > ControlMaster = auto > ControlPath = ~/.ssh/socket/control_%h__%p__%r__%l > > This means that whenever I connect to a new host, ssh creates a socket > that allows multiplexing new ssh connections on the already-established > SSH connection. After-all the SSH protocol was designed to support > multiple streams (for e.g. port forwarding). > > With this set, scp works nice and fast to a remote host. BTW: it seems > that in squeeze rsync now has the same sort of completion. > > As usual, I rely on the shell's history to provide me some sort of > context. I usually also copy pathes from a remote shell window on the > target system. Thanks, this is very neat ;) |