Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×

The Elusive Command Alias Function? 114

Posted by Cliff from the enhanced-terminal-software dept.
Meph_the_Balrog asks: "I work as a helpdesk jockey for a company that manages over 1200 linux based servers, across a huge area. Currently we use a Windows SSH client to provide remote server support, and I don't have the weight to convince management to deploy alias scripts to all of the servers we support. I admit this question may seem frivolous to some, perhaps dangerous to others, so I have a twofold question. Do any of you out there use a Windows based SSH client that supports command aliasing? If you have strong objections to this sort of technology, what inherent problems do you see with it?"
This discussion has been archived. No new comments can be posted.

The Elusive Command Alias Function? More

The Elusive Command Alias Function?

Comments Filter:
  • Alias scripts? Not sure what the author wants, but I see no problems in Aliases. If I am on the same brainwave, alias ls="ls -la", then I don't see any issues. I mean aliases are there for a long command with parameters or unknown or hard to remember commands. alias df="diskfree" for example. ok, bad example, but you get the jist.

    • I get what he wants. (Score:4, Informative)

      by Valdrax ( 32670 ) on Tuesday February 28, 2006 @06:19PM (#14821563)
      Okay, I get it now. Here's what the guy wants:

      He has no power to install his favored command aliases on all of the machine he has to administrate. He wants to have an SSH client (that he can run on Windows to connect to the Linux machines) that will interpret what he types and substitute aliases so that he doesn't have to set up his favored commands every time he logs into a system.

      I don't know if you can set an SSH session into a line-based instead of keystroke-based communication mode. By default, it sends messages to the remote server after every keystroke and not after enter is hit at the end of a line -- otherwise using curses-based applications would really, really hurt as would using tab-completion, vi mode, and other advanced shell features. If this can't be done, then a client couldn't interpret your commands before you send them.

      I don't forsee anyone providing this functionality because the demand is so low. This is the kind of thing that the remote end is expected to handle for you.
      • 1) Create a plain text file with all the alias commands:

        alias ls="ls -alF"
        alias nano="nano -w"
        ...

        2) Open connection to server in client of choice
        3) Open file in notepad
        4) Select All
        5) Copy selection
        6) Paste in connection window
      • He has no power to install his favored command aliases on all of the machine he has to administrate. He wants to have an SSH client (that he can run on Windows to connect to the Linux machines) that will interpret what he types and substitute aliases so that he doesn't have to set up his favored commands every time he logs into a system.

        This is a really easy problem to answer. Follow these steps in order:

        1. Make a list of all the servers and put it in a text file.
        2. Make your .bashrc in your home directory
        • for server in `cat serverlist.txt`; do scp .bashrc $i:; done

          Whoops, I meant:
          for server in `cat serverlist.txt`; scp .bashrc $server:; done

          • Re:I get what he wants. (Score:1, Informative)

            by Anonymous Coward
            This time you forgot "do", but even then you would get:

            sh: command line to long

            Not that many servers in your data-center, are there? :-)

            Try
            while read server; do scp .bashrc user@$server:; done serverlist.txt

            (because I wouldn't want my username duplicated for every server in the serverlist and I tend to avoid using cat without reason).

            Why anyone would use bash though is beyond me. My advice: Use something that you know will always be available by default, not something mostly used by Linux-users.

        • Re:I get what he wants. (Score:3, Informative)

          by Valdrax ( 32670 )
          The guy's not too stupid to figure out how to copy his aliases everywhere. He doesn't have permission to do so. That why both he and I both said so (including in the text you quoted).

          I am all too familiar with his conundrum, especially when it comes to being forced to work with inferior tools. I work in an environment where I am responsible for keeping production systems running, and I don't have admin install privileges. Even our admins don't have the political power to change things without serious pe
          • He (and you) doesn't even have the power to modify his own .profile, .bashrc and other environment files? If he's logging in as a "generic" userid, that should be addressed as a significant security hole first.

            • Re:I get what he wants. (Score:1, Insightful)

              by Anonymous Coward
              With good key management lots of role accounts are the right way to go. Create accounts for semi-root, one for read-only logs access, one for daemon control, etc. Give certain people different role access to different machines by copying their public keys appropriately and you have a very secure and easily managed infrastructure.

              Problem is, I happen to like vi-mode bash (set -o vi) but everyone would kill me if I put that in a .bashrc file on a few hundred machines for the debug role account.

              Ya dig?
            • He (and you) doesn't even have the power to modify his own .profile, .bashrc and other environment files? If he's logging in as a "generic" userid, that should be addressed as a significant security hole first.

              Not sure about the original poster, but we're doing (voluntary) Sorbanes-Oaxley compliance. I'm not even allowed to LOGIN to the production environment unless I submit a plan of work I intend to do, including risk, ways to avoid them, backup plan, concurring business stakeholders, etc etc. There is
          • The guy's not too stupid to figure out how to copy his aliases everywhere. He doesn't have permission to do so. That why both he and I both said so (including in the text you quoted).

            If he has a user-level account on the box, then he has permission to do what I wrote. And if he doesn't have a user account on the box, then how would he login in the first place. None of the stuff I asked him to do requires root.
            • There are two scenarios that I can think of off the top of my head could prevent him from doing so:

              1) He doesn't have permission to modify his own user account. Unlikely, but possible -- especially if /home is deliberately kept free of space or he's not given an actual home directory to prevent user customization and all he has is the shared shell resource scripts in /etc.

              2) He's got to use several shared administrative accounts (like root or various accounts for specific services), or the account he has
      • SecureCRT [vandyke.com] supports ActiveX scripting which means you can useany scripting language supported by WSH on your machine (like, say, ActivePerl). I think it will accomplish goal.
      • If this really is what he wants, and it seems the most logical interpretation, then I'd suggest simply placing a script like .my_aliases on each server, and then running ". .my_aliases" after each login.

        However, I have a STRONG aversion to lots of aliases, particularly for someone learning systems administration. When I first started using unix, the sysadmins in the Engineering department had set up a bunch of DOS-like aliases on our servers, so we would feel more at home. We came to depend on these, and a
        • "CS students were considered clever enough to learn Unix, whereas the Engineering students..."

          ROTFLMAO. Since when has a comp sci degree required a higher gpa then an electrical engineering degree.
        • There is a simple way to avoid the problems you so well state. Well, this being *nix we're talking about, there are several ways ... but, I digress.
          Have your home environment in CVS on a box somewhere. When you first log in to a machine that you know you will be doing some work on, say more than a ten minutes clean up job, you do a cvs check out ... voilà, all your stuff is working as you expect. Touch the ".myconfig/permanent" file if you want to keep your environment files on any given machine, othe
  • If they've got a command line HTTP or FTP client installed, then you don't need to "install" your alias script, just paste a command like

    `lynx -source http://someserver.com/with/my/script [someserver.com]`

    (note the backticks) when you first log in.
    • Lets not think about what would happen if someone else ever had write access to that remote script...

      With a bit of (bad) luck, he'd be running that script as root... *shudder*

      • Lets not think about what would happen if someone else ever had write access to that remote script...

        The same thing that would happen if someone else ever had write access to a special ssh client binary you use, or even to your local configuration files: he'd then be able to take over any account you logged into. If you have reason to think your ssh client computer is more secure than any file service you can write to, you don't have to paste a "run this alias script" command, you can just copy and paste t
      • They don't even need write access to that script, just IP spoofing or another means of replacing the insecure HTTP call.

        At least make it something like `ssh me@someserver cat /path/to/script`, although a minimal shell script that actually bothers to check exit codes and so forth is vastly preferrably. Execute via an expect script and you can get the behaviour you want without installing anything on the remote end.

    • Sort of clever, but it'd be infinitely easier and more efficient to put that in a network drive, then put ". /mnt/thatthingy/etc/aliases.sh" in their ~/.bash_profile. Pulling the thing with Lynx is kind of silly.

      • Sort of clever, but it'd be infinitely easier and more efficient to put that in a network drive, then put ". /mnt/thatthingy/etc/aliases.sh" in their ~/.bash_profile. Pulling the thing with Lynx is kind of silly.

        I agree, but the requirement that you can't install your script on the servers you administer is pretty weird to begin with. If he's not allowed to install a script, he probably isn't supposed to edit .bash_profile or mount network drives either - besides, if he could edit .bash_profile he could ju
  • Why not just use .bash_profile files with alias cmdyoulike='cmdyouwant' ?
    • Probably because as he said he doesn't have the power to deploy this script to all the servers they manage?
      • It's a freaking bash configuration file. Every user has one in their "home directory". If they are deviating this far from standard UNIX practices... then... I don't even have anything to say.

        You ssh to your account, your .bash_profile loads, you do your work, then you log out. I can't imagine how anyone could not be doing it like this.
        • Do you not get it? he has TWELVE HUNDRED MACHINES that he would have to put this .bashrc on. TWELVE HUNDRED MACHINES. Shall I say it again? I think the idea is that he might not even have a personal profile on them, since then every tech's profile would be replicated on TWELVE HUNDRED MACHINES. More than likely, he logs in as some "admin" user, and then fixes whatever is wrong with the box. I really can't imagine a hosting company setting up a profile for each of their helpdesk employees on each machin
        • They probably do, but they must have a lot of admins for 1200 servers. If they're all logging in as root (standard practice, albeit suboptimal), then they'd all be sharing a .bash_profile. Probably, management's fear of an alias messing up a real admin is higher than their desire to please a help-desk guy.

          Submitter: SecureCRT from VanDyke Software (about $90 if I remember correctly), will support login scripts. That would solve your problem nicely.

          If you can't afford that, or aren't allowed to install it,
        • It's a freaking bash configuration file. Every user has one in their "home directory". If they are deviating this far from standard UNIX practices... then... I don't even have anything to say.

          You ssh to your account, your .bash_profile loads, you do your work, then you log out. I can't imagine how anyone could not be doing it like this.

          In many large production environments, especially in systems that fall under SOX 404 restrictions, people don't have write access to their home directories. Often they have
  • Aliases? Windows SSH? Could you please rephrase the question?
  • yeeesh, I'm not sure you want to be doing this stuff if the solution isn't pretty clear. " ssh hostname 'command' " will execute whatever command you want on the remote machine. Use authorized_keys on the machines so the ssh goes through without a hitch. Use your scripting language of choice to send each command in a sequence to a list of machines.

    If you want to get really funky then add interaction to the script to allow inputing commands. If you are actually messing with multiple machines I submit it
  • You are managing the servers with no write access?
    • No, he is managing machines where he has to get aproval before using that write access. Maybe you have heard terms like "change management" or "production support".

      sure he could probably go and do it unilatterally, but thats a move that doesn't have alot of CYA in it. CYA is alot more important in some places than others.

      That said its not all about CYA, sure change management processes are often slow, and tedious, and often seem pointless for small changes.... but... nobody ever made a system problem worst
      • Yes, I expect change management. You know, I used to design run-books.

        Now, he has to work within the structure. And, within the structure, scripts can probably be deployed.

        Of course, making a script that enters from the keyboard via an SSH client playback macro so it doesn't have to go through the run-book is... kind of borked, no?

        If he DIDN'T have write access and was simply collecting information, such a dynamic script may be justified.

        If he wants to use this to introduce another management layer without
        • Now, he has to work within the structure. And, within the structure, scripts can probably be deployed.
          The submitter explicitly mentioned that he doesn't have the pull to get a script deployed across all 1200 servers. If your first thought is "why the hell not, if he's an admin who needs to manage all of these machines?," then I generally tend to agree.
        • Yes.

          I sort of assumed that it was more an issue of looking for a solution for a team of admins. You know... like I can put the cool tools I like in my home dir on all the machines I touch, but installing it for everyone else to use requires aproval.

          Also, ssh macros shared on a team seems fine to me. Its still only triggered when an admin is using it, and its not installed on the machine. Nobody has to go in as root and start pushing files around (or tell the distribution engine to push it out to the machine

  • What kind of aliases? (Score:3, Insightful)

    by stevey ( 64018 ) on Tuesday February 28, 2006 @04:49PM (#14820498) Homepage

    I'm guessing from the mention of Windows that you're thinking of things like:

    alias del='rm'
    alias dir='ls'

    Hard to say with such a vague question though, especially with the idea that the client must support the aliases. The clients I've used terraterm and PuTTY are the most commonly used, and putty at least doesn't support aliases. (Can't recall terraterm using them either, but I admit I didn't use it often).

    Personally I think that having DOS-style aliases is a mistake. Even though they might seem helpful to users of DOS/Windows it can cause problems when people realise the commands, even aliased, don't work in the way that they'd expect.

    Unless you could offer a 100% compatible environment it would be best to let people realise that Unix is different and work with it as it should be.

    • > it can cause problems when people realise the commands, even aliased, don't work in the way that they'd expect.
      > Unless you could offer a 100% compatible environment it would be best to let people realise that Unix is different and work with it as it should be.

      Perhaps I don't understand what you are saying, but how would it cause problems that don't already exist? If it is a case of people not understanding UNIX vs. DOS, it would be people not understanding aliases v. not understanding the UNIX com
    • Maybe I'm just on the same brainwave as the submitter, but it seems like a lot of folks are missing (what I perceive to be) the point. This guy admins a bunch of Linux machines. He does so from a Windows desktop, using a Windows SSH client like Putty or SecureCRT. He has some aliases that he likes to use on Linux; say like a couple of my favorites:

      alias h='history | grep -i'
      alias nmap='nmap -v -O -sS'

      Now, he doesn't want to have to login to 1200 different machines and edit 1200 different .bash_profiles and

      • The way you read the question seems to make more sense than the way I did.

        I'm not sure really how to handle this situation then.

        If the OP doesn't have permission to script the copying of some files to /etc/bash_completion.d/, or similar, I guess the question comes down to scripting the addition of the macros on all the client machines via a login script, or some other Windows-magic

        That might work out nicely if the users are all in a single Windows domain.

        I find the idea, though, of macros for SSH access

  • That sounds like a horrible idea. I'd hate to have to implement it. What's so hard about tossing out a single script that contains a bunch of alias definitions, and maybe running it in the default login script?
    • > What's so hard about tossing out a [...] default login script?

      I think the problem with that is that he wants a solution across multiple servers and multiple users. IMWO, I would guess he needs a SSH client that will automatically send a list of commands (contents of your suggested script, from some a central location) after the user is authenticated. But he would have to ensure evereyone's SSH client ran those commands. So I guess it's not a solution at all, unless he could force all of 'his' client
      • Hmm. At the university here, (at least in the CISE dept), we make good use of NFS. All users have one home, regardless of which server they login to. It would also be easy to place the script somewhere in NFS space. A per-user login script that calls the centralized script could be added to the skel structure so that all new users would receive it. It could be deployed to existing users with a script along the lines of "for each directory in /homes as x, if /homes/x/.login exists, append blah to it. Else, c
        • > we make good use of NFS

          Yeah, I remembered NFS just after posting, but didn't want to reply to myself. Even though he'd still need to go through all the paperwork, it might still be a good idea for his situation.
        • Hmm... at my company, NFS (as well as NIS) is banned. There are no networked filesystems on Unix boxes. I'm sure other companies have equally misguided policies.
      • IMWO, I would guess he needs a SSH client that will automatically send a list of commands (contents of your suggested script, from some a central location) after the user is authenticated.

        No, he just needs to run ssh under one of the standard pty programs like "expect" that can send a few commands for him after he logs in. Then he can do the scripting on his end, setting up aliases and whatever, and not have it affect any other users who log in with that account.

        I'd do it by keeping a regular .profile or w
  • so - just to make sure we're on the same page here:
    Aliases
    ( from man bash ) allow a string to be substituted for a word when it is used as the first word of a simple command. The shell maintains a list of aliases that may be set and unset with the alias and unaliases builtin commands...
    Script
    a program written in a scripting language. May be a shell script, perl script, ruby script, etc

    So... an alias is something you either set on the command line, or in your shell startup scripts. it's usually

  • >I don't have the weight to convince management to deploy alias scripts to all of the servers we support.

    I've only watched one episode of Alias, but it didn't really draw me in. But, irrespective of that, I don't know why you'd want to put the scripts to copyrighted shows on your servers, especially if they are publicly available.

    Maybe it's a Linux thing? people just want to do everything on Linux =-)

  • what are you asking? (Score:3, Informative)

    by corbettw ( 214229 ) on Tuesday February 28, 2006 @05:04PM (#14820682) Journal
    Are you asking how to set up an alias kind of like this:

    ruptime=`ssh $1 '/bin/uptime'`

    Then when you want to check the uptime on a remote box, you run:
    ruptime remote_host

    And do all this from a Windows box?

    If that's the case, you should use Putty. The Putty configuration can be set up to run a remote command, linked to a given hostname. Then when you open Putty, just select the proper 'alias' from the list, just like you would any host.

    I would expect SecureCRT has a similar function, but I haven't used it in a few years.

  • huh? (Score:1)

    by tscheez ( 71929 )
    since an ssh client logs in to a remote computer and the aliases are on the remote machine, local command aliases are not going to help. an unless i totally don't understand the question.

    what i can tell you want is a client that will read "dir" as you type it in and on the remote machine run "ls -lh" or something. i have never seen anything that would allow you to do that.

    i see no way of setting aliases without deploying it locally to each server, unless you have a roaming home directory.
    • > what i can tell you want is a client that will read "dir" as you type it in and on the remote machine run "ls -lh" or something. i have never seen anything that would allow you to do that.

      If it were telnet, a MUD client (eg, GMud) would do what he wants. However, I do not know of any SSH MUDs.

  • bleh (Score:3, Funny)

    by Intangion ( 816356 ) on Tuesday February 28, 2006 @05:23PM (#14820907) Homepage
    some of the ask slashdot questions are really getting stupid...

    do you guys think i should wear a blue shirt tomarrow? ive heard alot of people like blue shirts but i was curious if anyone knew of any problems wearing blue shirts?

    • >do you guys think i should wear a blue shirt tomarrow?

      I Hear Mauve has more RAM

    • Blue shirts should be fine. We have however had some problems reported by staff wearing red shirts. They keep getting sent to die at the hands of aliens. Keep this in mind when planning your wardrobe.

    • Re:bleh (Score:2)

      by CMiYC ( 6473 )
      IRC Answer:
      Blue shirts are teh suck. Any noob 1D10T knowz that!

      Ask Slashdot Answer:
      Huh? Wear a shirt? Why would you want to do that? We need more information. Where do you work? What is the dress code where you work at? Are you trying to impress anyone in your office? What size shirt do you wear? Do you know how to tie a tie? God. The stupid fucking quesitons have to stop! If you're going to ask us a question, give us all of the information. Maybe we can think of a solution you didn't.

      For examp
  • I think the author is looking for a way to run the same commands on multiple servers at the time to ease administraton. I should not that although the servers might be set up the same, running multiple commands on multiple servers can/is dangerous, since you don't see the results clearly. Quick google: http://tinyurl.com/sxfkh [tinyurl.com] http://tinyurl.com/qxr4n [tinyurl.com]
  • Mod me troll, I don't care, but I think Cliff should be ashamed of having posted this.
  • I can see the benefits of such an arrangement.

    But I see no benefits of staying on Windows. Bottom line: switch to Linux or BSD like everyone else managing multiple remote servers and reap the benefits. It's as simple as:

    $ ssh remote.host "cd /home; pwd"
  • The use of command aliases is a good way reduce command complexity, thus reducing the number of typographical errors (and the resulting operational errors) when doing support.

    That, by itself, could be a strong case for allowing an approved subset of aliases on your set of supported servers. Demonstrate a case where a simple typo could be catastrophic.

    Typically, however, those aliases are resident in the shell local to the server, not in an ssh client (which usually provides pass-through access to the shell
  • Maybe you are looking for a way to run a specific command without logging in? This can be done with key authorization. The command must be named before the key in authorized_keys (OpenSSH), which looks something like this:

    command="/some/script/or/something.sh" ssh-rsa user@host
  • Ok, my bad for attempting to keep the question "to the point".

    Since I work in a corporate environment, my choice of workstation operating system is well beyond my control, even more so than my ability to deploy command aliases to each individual server. I'm also on helpdesk, so I have no direct administrative access, just a limited shell account that is shared between myself and 5 other techs. I could try and make a business case for command aliases being deployed to all the servers, but as a helpdesk t
    • Ahhh....Then I think the earlier comment about keyboard macros is apropos. My 2 cents is to run out and buy a Nostromo [belkin.com] if the let you install the software. The programming ability of the unit is amazing and it will allow you, once you get used to it to hit one key or a combo of keys to get things done. They are also cheeeeap! I have never tried one over putty, but I would imagine that it would still work. There are also keyboards with memory on them that dont need a software install, the ones I have seen ha
    • I'm sorry that no one got what you were asking for, and I wish that I could help, but I'm in a similar boat with no paddle. Personally, I don't use aliases very much, but I've grown to hate ksh88 and miss my bash and tcsh so very much. (I want my command substitution and '!!' back!)

      On the other hand, I have leared to stop worrying and love the vi mode.
  • Unless you trust that the windows box is not ever going to grab your local keystrokes, capturing your username/password information for the nix boxen.

  • try configuring the clients to set the environmental variable PROMPT_COMMAND to "eval alias dir='ls -l' ; eval alias del='rm -i' ; eval PROMPT_COMMAND="

    </lame>
  • is a number of bash scripts on servers he manages that perform complex series of command line tasks with a single command executed by the helpdesk operator. Not a bad idea, as it eliminates the potential for human error by unskilled or unwary operators, but i can see why it wouldn't have been rolled out by the tech staff or approved by management: If i was a helpdesk operator in a company managing linux servers, my only way up the ladder would be by increasing my skillset in the managed environment. Having
  • sooo.... is anything stopping you from just pasting in a bunch of alias commands when you start the ssh session?

    leave a notepad window open with the alias commands selected if you do it a lot.
  • A ssh client that will let him alias bash commands client side. In other words he is not allowed to copy his tweaked out .bashrc to all the servers (1200 boxes apparently) and he wants his aliased commands to be the same no matter which box he logs into despite not having them setup in the local profile. Unfortunately I am not really sure how to do this, since I memorized the actual commands instead of aliasing things. *I probably should use alias more but meh.
    • Please mod up - this is almost exactly what I was asking for =) (there are others who have said similar, but none quite so concise)

      • Well, if this is the case, then just find a similar approach to some of the other suggestions...

        1. create your alias script on the local machine
        2. copy/paste script into terminal OR record as macro OR something else similar
        3. run this macro/paste/whatever each time you log in to remote server

        Once set up, step 3 should only be one extra click to save time and effort.

        • Keep the aliases in a file in your home directory. After login, source ~me/aliases

          That way you don't need to worry about flaky cut/paste buffers.

          (If you don't have a home directory because you're logging in straight to the root ID, then the sysadmins are clearly a bunch of idiots.)
      • The type of interface you're thinking about is something along the lines of a text-based MUD or IRC client, where your commands are hooked BEFORE being sent to the server. I personally don't know of any, but can't imagine that it hasn't been considered. Currently, OpenSSH uses the "~" character to indicate that an SSH command will follow. "~C" drops you to an "ssh>" prompt to add things like tunneling while you're still connected to the host. Evidently, the ability to intercept input and redirect it
  • Since there seems to be some confusion as to what exactly he's asking for, here's my 'guess'. He manages these 1200 linux servers, and wants to use his commonly used aliases on all these boxes. Common sense says he has write access, he's just looking for a way to use his aliases across the entire network of servers, and not have to 'install' an alias file or whatnot everytime he logs in to a new box. I think he's asking for some way to store the aliases locally, so that when you type 'ls' into the SSH clien
  • Here's a semi-automatic way of doing it:
    1. Put all your alias commands in a text file on your Windows machine
    2. After you log in to a machine, paste the text in at the prompt

    Sure it's a pain, but it works. You could even put in something like:

    cat >> .bash_profile
    echo No Aliases Required
    alias 'l=ls -a'
    ...

    Then paste that in and press Ctrl+D. That way, it will put in the aliases each time you log in to that machine. If you don't see the message that says "No Aliases Required", then you know you need

  • Although I hesitate to offer any advice that will increase productivity in a company so unpleasant that they won't let their employees create .profile files, here's something that may work.

    First of all, if you can possibly find a way to create your aliases within the shell of the remote machine, do so. There are two reasons:

    1 - Only the remote shell knows enough about the context of your input to interpret aliases reliably. Your ssh client will be flying blind, and trying to get something that's functiona
  • Server-side:

    If you're using a shell that supports functions (i.e. bash), then you can get a lot more functionality by defining functions in your .[bash]rc file. For example:

    function findhere() {
    loc='.'
    [ -n "$2" ] && loc=$2
    find $loc -iname "*$1*"
    }

    ...is one of many I use, 'find SOMEWHERE -iname "*PARTNAME*"' becomes 'findhere PARTNAME SOMEWHERE', with SOMEWHERE defaulting to the current dir.

    Client-side:

    Most SSH clients (i'm sure i'll get corrected) will not pre-process

  • One easy way to accomplish this is to run cygwin http://www.cygwin.com/ [cygwin.com] on your windows box, setup all of your environment variables there (aliases and anything else you want), and have SSH pass your environment variables when connecting to a new box. With cygwin you get the standard openssh client, so anything you could do on a gnu box you can do there. You can get this all working and not have to change anything on the actual servers, it will all happen "automagically" on any server you log into, as long
    • setup all of your environment variables there (aliases and anything else you want), and have SSH pass your environment variables when connecting to a new box.


      Hmmm. I've always thought of aliases and variables as very different sorts of beasts. Is there a way to manipulate aliases as though they were environment variables? (In one of the common shells?) Sounds like it could be a handy trick.
  • They have two options for this:

    1) Cygwin
    2) Dedicated Shell Server
    Within this environment you will use fanout [stearns.org] from Bill Stearns [stearns.org]

    A) If the remote systems are not set to ``UseLogin yes'' in sshd_config then the custom environment can be used with environment='whatever=whatever' in the remote ~/.ssh/authorized_keys. This, of course, would also require a key which may not be possible as well as ``PermitUserEnvironment yes'' set in sshd_config.

    B) The env channel from the ssh client can set the environm
  • If you don't like whats provided by your ssh client, how about wrapping a windows commandline ssh client like putty with Expect?
    http://expect.nist.gov/ [nist.gov] for Expect and some usage examples
    http://tcl.activestate.com/ [activestate.com] for Expect for Windows

    Just define all the convenience functions you need as simple expect scripts and don't look back. If you like GUIs add some trivial Tk code.
  • expect can do what you want. You would start ssh inside expect, and program a simple script for expect so that it spews out the aliases at the right moment. The hardest part would be to find which of the 'expect's that exist for windows will do the job.

    I don't know expect, but the script will probably look something like this:
    spawn ssh [lindex $argv 1]
    expect ">"
    send "alias this=that"
    send "alias ls=dir"
    interact
  • Check out a company called Blade Logic. They make server management software that probably can do what you are looking for. http://www.bladelogic.com/ [bladelogic.com]
  • If so, set up all your aliases in said file, and then "source" that file when you login. An extra step, but, it's not to hard to type "source .aka" ... unless I am missunderstanding the question.

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close